Marketingové video - uděláme až nakonec. Instruktážní videa - Howto na konkrétní téma: 00 - intro video - ukazující přehled funkcionality v systému kde již jsou devices: přehled, zařízení, vyhledání zařízení s , alert. vyhledání alertu, misslý alert, flash FW, webtunel 01 - jak přidat device do MAMAS - Adv. router, Teltonika rout., OpenWRT, Linux 02 - jak organizovat devices do skupin, naming, labeling, vyhledávání 03 - alerts 04 - changes tracker 05 - agent profiles 06 - Automated Agent Deployment 07 - Firmware Management 08 - webtunnel (AdvR ?) 09 - jak provést upgrade licence 10 - jak klonovat konfiguraci (AdvR) 11 - jak nastavit notifikace (e-mail a slack) 00 - showcase Welcome to the Dwarfguard showcase video. Dwarfguard is a software to guard your devices, focusing on industrial cellular routers and Linux devices. In this video, we will go through example usage, showing some of the features. If you are interested in details, follow to the specific video guides. Manualy adding one device is easy - download the agent, open device web pages, install as any other router app. [Do this on empty install, manual install on advrout2] Looking into Device Details on the server you can see the actual reported data and also historic data for some selected metrics. Let's review supported device types. Next to the Advantech cellular routers, Dwarfguard supports Teltonika cellular routers, OpenWRT devices and provides generic Linux client able to run on virtually any Linux distribution. For mass deployment on many devices, there is the Automatic Agent Deployment tool. The most versatile organization technique is using Monitoring Groups. Let's create first a monitoring group for our routing infrastructure, calling it backbone. Let's call the new group backbone. Once created, we assign the routers into the group. Next to the Advantech routers, there is also a Linux fileserver part of the backbone. Each and every monitoring group is shown on the Dashboard. You may notice the All devices system monitoring group that encompasses all of your devices all the time. The monitoring group lights breakdown offers a shortcut for quick navigation to subset of devices in that particular state. Devices in the backbone group are quite important to us. By assigning a different agent profile to these devices, they will send data more frequently starting with their next contact with the server. The layout of the Devices table is customizable. Let's go to System->settings and add the Agent Profile column. By filtering the devices so that only those being part of the backbone monitoring group are shown, we can verify that the agent profile has been assigned. Next we create monitoring group for the devices installed in our trucks. Once the group is created and devices assigned, we will also switch all the devices to the slowest agent profile. The trucks may be offline for a number of days so there is no point in getting alerted in this case. You may edit the agent profile time values in Agent Profiles. Remember, the device always reports data after boot, which plays quite well with devices that are not being up all the time. The last group we create is for our computing cluster. After creating the group we assign all the Linux devices but the fileserver into that group. Let's create a custom alert for the cluster. Go to Alerts and start defining it. The alert name is used in the e-mail or Slack notification so it is good to pick something accurate. Dwarfguard supports two alert types - alert for a single device and alert for a group. We will define alert for a group. Pick the cluster monitoring group. Our cluster consists of five nodes. Let's say that once four or more nodes are under load, we would like to get alerted. The suitable metric to use could be the average load for 15 minutes. The load value to be checked depends on your preference. Remember, you can edit the alert at any later time if you find out the definition is imperfect to your needs. The server will pick the new alert definition in a few seconds. Once that happens, the alert get's listed on the monitoring group entry on the Dashboard. Looking into alerts, you may notice there are some factory-defined alerts. You may disable, edit or remove these as you wish. Let's also prepare more strict alerts for the backbone monitoring group. First guarding the device temperature, specifying a lower temperature than the one being checked for All devices. Second alert will trigger anytime the backbone device misses a single data push. The global light icon at the top that always indicates global system state is auto-reloaded and serves also as a shortcut to the dashboard. Once at the Dashboard, we see there is a problem with one group. Locating the group indicates there is a raised alert. All raised and past alerts are listed below the group breakdown, including a listing of a few devices for which the alert is raised and also a shortcut to the table listing all of them. Following to the device details we see that the actual data shows 0 missed contacts. The device was probably delayed by only a several seconds. Our alert definition is very strict and the alert will lower on next alert evaluation, that happens every 30 seconds. For the sake of demonstration, let's suppose we really suspect a problem with the device. We setup a webtunnel, which is a tunnel initiated from the device side to the server, allowing us to login to device local web interface through the Dwarfguard server. Note that the unique tunnel link does not require logging into the Dwarfguard server itself, allowing you to pass the link together with the device web logon credentials to a 3rd party if you for example want to allow support company to access the device. But what if the alert lowers before we have a chance to look into the system? The answer is that it will count as a past alert. Regardless there is a notification sent out or not, no alert being raised is discarded. You can review the past alerts on the dashboard, listing all the affected devices. Once you possibly take an action and acknowledge the alert by clearing the counter of alert detections, the system returns to all green state. Sometimes just the device details are enough to help you - in this example, the device is too hot and just by scrolling down to the history statistics, you can see the device availability is not 100%. Also, there is a nice tool that can help you to find out extremes among your devices. If you visit the Changes Tracker, you may for example select a metric and quickly find out the device reporting e.g. most reboots, together with dates when the reboot was detected on the server. Optionally, you may also filter the date to a specific timeframe. Now let's say you have a device that misbehaves frequently and you are sick of constantly reviewing alerts for this device. The router manufacturer is telling you it will be fixed in new firmware. A simple technique to remember that this device is to be flashed later when the firmware becomes available is to create a label. You can use the label later on on the devices table to filter out only these devices with the label assigned. When there is a new firmware produced, go to the software manager, firmware, and add the new firmware version there. Once Dwarfguard downloads the firmware, and the particular firmware version is approved by you, you can assign it to the supported device types. Go to device details, pick the desired firmware version and confirm. The device status will switch to Pending state and once device comes with next data push, it will pick the firmware flash command and perform the operation. Looking at the agent logs on the device, you can see a log entry regarding the firmware flash operation. After the reboot the device reports the new firmware version to the server and will return to the synced state. Our brief walkthrough over some of the features is over. What didn't fit? Want to run SaaS or on premise? Both supported! Have many devices? Look at the performance testing results, Dwarfguard is able to handle tenths of thousands of devices. To try out you can either ask for a demo or simply download a free version with limited number of device seats if you want to run the software on your own server. 02: - There are a few ways to organize your devices. - For the purpose of individual identification you can name the devices. [ open Devices, name a two devices, similar name with common part ] - You can use the name column to filter out or sort. [ showing the filter out using name ] - The name of the device is also visible in a number of selection boxes next to the Device ID, allowing you to quickly find the device which name you do remember. - Another technique is labeling the devices. - First you need to define a label. [ Defining two labels ] - Then you can assign the labels. That can be done individually on Device Details or as a mass action on the Devices table. [ Adding router label to non-linux devices ] - The device can have multiple labels. You can use labels for filtering or searching. - A little bit high-level organization is done using Monitoring groups. - We will add a few Monitoring groups first [ Creating monitoring group Critical ] - You can assign a device to a monitoring group on a Devices table. [ Adding devices to Critical ] [ Switch to the Dashboard ] - All the monitoring groups are shown on the Dashboard. - The Dashboard data is updated in a timely fashion, so it can take a while for the data to be updated. - The group All devices is a system group and all devices are automatically members of this group. - Groups are handy for defining group-specific alerts. - Let's define some alert for the Critical group. [ Alert for critical group - if load15 is over 4 ] - Now if any of the devices in the Critical group is loaded, an alert is raised. 03: custom alert + notifications preface: Alerting system is important feature under the monitoring area. It can satisfy a number of use cases, the primarily one being showing the devices that are misbehaving. Alerts are quickly identifiable and can optionally spawn a notification send via e-mail or Slack. Let's have a look at the situation when some alerts are raised. Dashboard is showing two raised alerts. In the displayed case, there is an alert raised. We see it immediately in the global light and by following the red light trail we can quickly see that the alert raised is on the All devices group. The devices triggering the alert are listed below, allowing for quick access from the dashboard - both to the devices and to the alert definition in question. We see that we have an alert raised although we have not defined any alert. That's because there are some basic alerts defined in the Dwarfguard by default. Let's review these alerts. Any alert defined can be either deleted, disabled or edited. Let's disable the raised alert now. Alerts are evaluated in a timely fashion so it could take some time until our request to disable the alert is evaluated but it should usually take up to a minute at maximum. By disabling the alert, there is nor guard active checking the devices temperature. Let's remedy the situation by editing the alert. We update the threashold value, setting it a little bit higher. Now we enable the alert again. As the current alert definition is a little bit loose for ome of the more sensitive devices, we create a new monitoring group now. Once created, we assign the sensitive devices to the new monitoring group. Next, we define a new alert with the more strict temperature check. This new alert will be defined on the monitoring group containin these temperature-sensitive devices. As you can see, there is a number of metrics to choose from and also a number of ways how the condition can be defined. The new alert will be active in a while and once the next alert evaluation happens (in under a minute), all the devices in the monitoring group gets evaluated against the temperature threshold. When a device triggers an alert and later on the device returns into the regular metric values, the alert is no longer raised. Still, the system remembers that there was an alert triggered and lists the alert as Past alert, leaving it for the review by administrator. To acknowledge the alert, click on Clear alert. If you want to setup the notifications for alerts being raised, please follow to the notifications setup video. 05: agent profiles Preface: Agent profile is a set of settings for the agent running on a device. By using the various agent profiles for different devices you can achieve different data reporting period, thus making the critical devices provide data updates more often and the slow and offline devices to provide updates only infrequently to save cellular traffic. Agent profiles are shown under the Agent Profiles menu entry. In Dwarfguard 0.8.0 there are three agent profiles available to the user. The profiles have fixes name and the DEFAULT profiles is the one that is being automatically assigned to the newly registered devices. You can customize any of the defined values. Adding custom agent profiles will be supported in later versions. To assign agent profile to the device, you can either use Device Details individually, or use mass action from the devices table. Note that you can also enable displaying the Agent profile in the Devices table, allowing directly showing the profile assigned or sorting/filtering functionality. 06: Automated Agent Deployment - [1st screen] - Devices are added to Dwarfguard by installing an agent on the device. - You can use either a device web interface or a command line to do that. - But if you have many devices, manually installing one by one becomes unfeasible quite quickly. - We are going to look at automatic agent deployment that can resolve the situation. - [2nd screen] - To push the agent to a device, the device must be reachable from the computer running the push. - [3rd screen] - First we look at running the push directly from the server where Dwarfguard is deployed. That is usable in the case the server is on the same VPN as the devices, if it is on the same LAN or if your devices are accessible from the Internet. However, leaving devices ssh port accessible from the Internet is usually not preferred. - The push process will contact your devices one by one via SSH protocol and install the agent automatically. Once the device registers, it will switch to the next device. - [4th screen] - You can also run the push process from another machine. Typical example is from a Notebook that can be connected to the same network your devices are residing at. - This is also usable in case you are using Dwarfguard in the Software as a Service mode as in that case you do not have command-line access to the server and thus cannot run the push process from there. - Both ways of running the automatic agent deployment are the same. The only thing you need for the scenario B is to prepare the tool on the Linux machine or Linux VM. - [5th screen] - We will do this directly in this video. To sumarize the steps, you need to download the tool first. - Next, you download the agent archives from your Dwarfguard server. Remember you must always download the archives as they contain unique server ID so you cannot use agent archives from one server to register the devices to another server. - Before running the tool, you need to put all the downloaded files into a directory structure. - Once done, you continue exactly the same way you would apply from the server itself - prepare list of devices and then execute the tool. - Lets do the preparation now. If you are going to run the tool from the server, you may skip the preparation phase. 07: Firmware Management - Firmware Management for supported device types is under SW Manager -> Firmware. [ SW Manager -> Firmware ] - You can add a new firmware version manually [showing adding a version]. A new firmware version is also added automatically once a device with unknown firmware version registers to the server. - When a new firmware is added, it is not available, meaning the firmware files are not present on the server. [ showing the Event Log ] - The server starts attempting the firmware files download. Once the firmware download finishes, the firmware version becomes available. [ Event log showing download is finished ] - If you want to be able to flash a particular FW version to a device, you must first approve the version. [ Approving the version ] - Setting the desired FW version is done in Device Details. [ Changing the desired version in Dwarfguard ] - Once set, the Synchronization status of the device is set to Pending if the device does have a different version. [ Showing Devices ] - Once the device comes with an update, it processes the FW upgrade command and begins FW download and FW upgrade. - We will expedite the device data push from the agent UI on the device web pages now. [ Expediting ] - If you keep the FW version set, Dwarfguard will keep the device on the desired FW version. [ Devices table when FW upgrade is done ] - The FW upgrade is stored in the agent global log [ Showing agent global log + path to the log on the deivce (/opt/adwarfg/global_log.txt) ] 10 configuration cloning Configuration cloning is a feature with very narrow use case but fulfilling this use case fully. If have have a number of devices in the exactly same deployment - like a number of facilities where the device performs the same role with exactly the same settings, this feature is the one you may be looking for. Otherwise, it is probably not what you are looking for. Configuration cloning works between devices of the same type only. Also, it works only for device types that are able to send and receive a configuration profile. At the time of Dwarfguard 0.8 that means the Advantech routers device type. The configuration profile contains all the configuration processed by the device. If you setup the cloning, the target device will set all its configuration options according to the cloning origin. There is no limit and no exception of this. Please note, that stuff like ethernet IP address is part of the configuration profile for Advantech router, so it gets cloned. On the other hand, installed firmware version is not a configuration key. During the cloning procedure, all the applicable configuration values are cloned. Values, that are not applicable to the clone target have no effect. Example of this is when the source device of the cloninig does have a wifi and the target does not have it. Let's first review the device state before cloning. Now we setup the cloning. After the cloning is setup, lets look at the IP address. The cloning operation is being maintained. This means that any new change done on the source device gets cloned onto the target device. Also, if target device configuration diverges from the applicable configuration of the source, it gets corrected automatically. Let's try it out by updating the startup script change on the source device. Showcase ending: Our brief walkthrough over some of the features is over. What didn't fit? Want to run SaaS or on premise? Both are supported. Have many devices? Look at the performance testing results. Dwarfguard is able to handle tenths of thousands of devices. To try out the SaaS, you can ask for a demo being setup for you using the mentioned URL. Another point worth mentioning is that the Dwarfguard is an actively developed product and there is also a possibility for custom development. If you want to try the product out in your own environment, you can download the free version and deploy the software on your own server with no strings attached. Thanks for watching. Ending: To watch other Dwarfguard videos or find related information, follow the displayed links.