I am trying to see the best way to restart the Raspberry PI from Cumulocity, out of the box using PI agent.
This is a use case where the CPU temperature of PI goes up, Cumulocity will trigger a restart. So far the work I have done does the following
Send measurements from PI via MQTT (python paho client). I can see
them show up in Cumulocity
Using Shell options in cumulocity UI, I send a manual a manual
restart message
Subscribe the restart message in python client and then issue a
restart to PI
To summarize I would like to how to read the measurements received in Cumulocity and if it reaches above a certain value, trigger an automatic restart of the PI device. That is skip steps b and c above and make it automatic.
Thanks for your help,
JM
If you see the measurement in the data point explorer, select "Create Smart Rule" and either "On measurement threshold create alarm" or "On measurement explicit threshold create alarm". Configure the threshold and the alarm type.
When you see the alarm, click on it and again select "Create Smart Rule", using "On alarm execute operation". The template has already restart in it, so you can just click OK.
You can do the same directly by clicking on "Smart Rules", but then you have to enter the measurement names and alarm types manually.
Related
Is it possible to notify an application running on a Google Compute VM when the VM migrates to different hardware?
I'm a developer for an application (HMMER) that makes heavy use of vector instructions (SSE/AVX/AVX-512). The version I'm working on probes its hardware at startup to determine which vector instructions are available and picks the best set.
We've been looking at running our program on Google Compute and other cloud engines, and one concern is that, if a VM migrates from one physical machine to another while running our program, the new machine might support different instructions, causing our program to either crash or execute more slowly than it could.
Is there a way to notify applications running on a Google Compute VM when the VM migrates? The only relevant information I've found is that you can set a VM to perform a shutdown/reboot sequence when it migrates, which would kill any currently-executing programs but would at least let the user know that they needed to restart the program.
We ensure that your VM instances never live migrate between physical machines in a way that would cause your programs to crash the way you describe.
However, for your use case you probably want to specify a minimum CPU platform version. You can use this to ensure that e.g. your instance has the new Skylake AVX instructions available. See the documentation on Specifying the Minimum CPU Platform for further details.
As per the Live Migration docs:
Live migration does not change any attributes or properties of the VM
itself. The live migration process just transfers a running VM from
one host machine to another. All VM properties and attributes remain
unchanged, including things like internal and external IP addresses,
instance metadata, block storage data and volumes, OS and application
state, network settings, network connections, and so on.
Google does provide few controls to set the instance availability policies which also lets you control aspects of live migration. Here they also mention what you can look for to determine when live migration has taken place.
Live migrate
By default, standard instances are set to live migrate, where Google
Compute Engine automatically migrates your instance away from an
infrastructure maintenance event, and your instance remains running
during the migration. Your instance might experience a short period of
decreased performance, although generally most instances should not
notice any difference. This is ideal for instances that require
constant uptime, and can tolerate a short period of decreased
performance.
When Google Compute Engine migrates your instance, it reports a system
event that is published to the list of zone operations. You can review
this event by performing a gcloud compute operations list --zones ZONE
request or by viewing the list of operations in the Google Cloud
Platform Console, or through an API request. The event will appear
with the following text:
compute.instances.migrateOnHostMaintenance
In addition, you can detect directly on the VM when a maintenance event is about to happen.
Getting Live Migration Notices
The metadata server provides information about an instance's
scheduling options and settings, through the scheduling/
directory and the maintenance-event attribute. You can use these
attributes to learn about a virtual machine instance's scheduling
options, and use this metadata to notify you when a maintenance event
is about to happen through the maintenance-event attribute. By
default, all virtual machine instances are set to live migrate so the
metadata server will receive maintenance event notices before a VM
instance is live migrated. If you opted to have your VM instance
terminated during maintenance, then Compute Engine will automatically
terminate and optionally restart your VM instance if the
automaticRestart attribute is set. To learn more about maintenance
events and instance behavior during the events, read about scheduling
options and settings.
You can learn when a maintenance event will happen by querying the
maintenance-event attribute periodically. The value of this
attribute will change 60 seconds before a maintenance event starts,
giving your application code a way to trigger any tasks you want to
perform prior to a maintenance event, such as backing up data or
updating logs. Compute Engine also offers a sample Python script
to demonstrate how to check for maintenance event notices.
You can use the maintenance-event attribute with the waiting for
updates feature to notify your scripts and applications when a
maintenance event is about to start and end. This lets you automate
any actions that you might want to run before or after the event. The
following Python sample provides an example of how you might implement
these two features together.
You can also choose to terminate and optionally restart your instance.
Terminate and (optionally) restart
If you do not want your instance to live migrate, you can choose to
terminate and optionally restart your instance. With this option,
Google Compute Engine will signal your instance to shut down, wait for
a short period of time for your instance to shut down cleanly,
terminate the instance, and restart it away from the maintenance
event. This option is ideal for instances that demand constant,
maximum performance, and your overall application is built to handle
instance failures or reboots.
Look at the Setting availability policies section for more details on how to configure this.
If you use an instance with a GPU or a preemptible instance be aware that live migration is not supported:
Live migration and GPUs
Instances with GPUs attached cannot be live migrated. They must be set
to terminate and optionally restart. Compute Engine offers a 60 minute
notice before a VM instance with a GPU attached is terminated. To
learn more about these maintenance event notices, read Getting live
migration notices.
To learn more about handling host maintenance with GPUs, read
Handling host maintenance on the GPUs documentation.
Live migration for preemptible instances
You cannot configure a preemptible instances to live migrate. The
maintenance behavior for preemptible instances is always set to
TERMINATE by default, and you cannot change this option. It is also
not possible to set the automatic restart option for preemptible
instances.
As Ramesh mentioned, you can specify the minimum CPU platform to ensure you are only migrated to an instance which has at least the minimum CPU platform you specified. At a high level it looks like:
In summary, when you specify a minimum CPU platform:
Compute Engine always uses the minimum CPU platform where available.
If the minimum CPU platform is not available or the minimum CPU platform is older than the zone default, and a newer CPU platform is
available for the same price, Compute Engine uses the newer platform.
If the minimum CPU platform is not available in the specified zone and there are no newer platforms available without extra cost, the
server returns a 400 error indicating that the CPU is unavailable.
Not sure if this is possible but here it goes. I have a simple server set up where multiple clients could execute a program. Each time a client executes the script to start the program, a new instance of the program starts. Now when the client stops the program execution thru another script, the instance of the program is killed. The problem is if another client is on the server at the same time running the program that instance will be killed also. Is there any way to connect a particular instance to a particular client?
Here is more detail.
The server is used to stream media from the internet. I have streaming devices attached to tvs. When a particular channel is selected, it sends a signal to the server which in turn runs several scripts, one being a script to start a video conversion process thru program called ffmpeg. The ffmpeg coverts the stream, saves it to a folder on the server making it available to the streaming device/tv. Each time a user starts a channel, an instance of the ffmpeg starts because its converting a different stream. Once the user ends viewing, the device sends a signal back to the server thru php script, which in turn runs a script called cleanup. The cleanup script is a bat file that kills the ffmpeg and deletes the files that are no longer needed. All works great except if one individual elects to stop viewing while the other continues. I don't know how to tell the difference between each instance of ffmpeg. I don't want it to kill all instances just the one connected to the one particular stream that needs to end. I do have the capability of obtaining each device ip address when the user first selects the channel. Is there anyway to link the ip to the particular instance?
Actually took advice from above and renamed each instance as ip, stored ip in temp file, was then able to match it to the ip making the cancel call.
How can I monitor traffic going out of a wcf service (self-hosted) on Windows Azure ? The amount of data going into my stress-test app doesn't seem to add up to what I'm seeing on the pricing page (which doesn't seem to be updated live anyway). The service is using https and messages are pretty small. Is the SSL handshake traffic negligible? I also have a data-miner worker roler that continuously downloads data from the internet, but from what I've read, inbound traffic is free, so it shouldn't count in the OUT traffic.
How can I get a reliable traffic monitor?
Billing page is usually updated once a day (once in a 24hr period). So you have wait a lot until you see results of your stress test added to the billing page for your account.
One place that you can monitor this (among other KPI for you application) is the MONITOR tab in the Management Portal. You can navigate to your Cloud Service being under test, click the MONITOR menu item, then click on the Add Metric at the bottom, and finally chose Network Out. This monitoring dashboard gets data every 5 minutes so it shall reflect network usage you are talking about.
Here is a screenshot of how to achieve this:
Other option that you have is to use a Network Performance Counter such as Network Interface : Bytes Sent/sec. You have to configure Windows Azure Diagnostics to monitor that specific performance counter. You can then set a scheduled transfer period of 1 minute and dig into the table created by the diagnostics agent for data.
P.S. And yes, you are correct - INBOUND data for Azure is FREE.
I am currently building a server using Debian Squeeze. It will be administered by myself and a friend, and I am wondering if it is possible to forward the output from ONE process to TWO clients.
As an example, process abc is running on the server. It uses X for graphical output. I would like to be able to view and control its X window on both client computers at the same time. This way, both my friend and I would be able to see the status of process abc and send commands to it from our remote computers. The only solutions that I have found so far indicate that the process can only connect to one X instance at a time, requiring that for me to see the X output, my friend would have to disconnect. Is there a way for both of us to connect and control the same process at the same time?
I am afraid that X forwarding allows only one connection. However, you can try VNC to achieve your desired setup.
You maybe able to use VNC to control the remote desktop (the (Archlinux Wiki) states that you maybe able to set x11vnc to forward the root desktop, which you both may be able to access at the same time; I haven't tried it so I can't say for certain).
I have a specific device driver which is used to do Motion Control over the parallel port on my machine.
I'm told that the issues I'm having are caused by other windows processes taking away it's CPU time.
So i want to change the priority fo the thread for this device driver (Mach3.sys) to realtime.
But I can't find it in the Process list in task manager.
Does anyone know how to get it show up, to alter it's priority in another way, or
if it's run inside another process what exactly that is.
, so that I can alter it's priority.