Monitoring is hard, but quite worthwhile if done correctly. In my opinion, most of the challenges when implementing monitoring, are related to
- Organisational structures. Split project and operations teams / organisations. Separation of concerns and no shared responsibility.
- Lack of communication. Waterfall like projects, teams on different locations.
- Functional focus. The customer often prefers to spend money on new functionality instead of non-functionals which are often not immediately visible to the outside world and often harder to sell.
In order to provide something simple to provide a minimal set of information to development and operations teams, I stumbled upon simple-dashboard. An open source project on Github. This dashboard provides a quick and easy way to monitor various endpoints. Its (JavaScript / HTML) code runs entirely from the browser and does not require a separate server. Configuration it done with a simple JSON file.
Simple dashboard
Getting started
On the simple-dashboard site, there is a description on how to get started. It's as simple as:
Install git, install Node.js.
npm install -g grunt-cli
git clone https://github.com/Lugribossk/simple-dashboard.git
cd simple-dashboard
npm install
After these initial steps, you have 2 options to run the dashboard.
- Start a local development server: grunt dev. This refreshes the browser after you make changes to the JavaScript code. It runs a local Node.js server on port 8080. You can access the dashboard by accessing localhost:8080 in a browser.
- Make a distributable version: grunt build. This creates a distributable version of the required files to run the dashboard. You do need to provide a relevant config.json next to the index.html file. You can access the dashboard by opening index.html in a browser.
Runs in just the browser. No server required
There are customers who do not readily create new servers. This is especially true in organisations who have not implemented automated provisioning or have not implemented a cloud solution. In such organisations, creating a new server is hard and thus expensive. If you can avoid having to use a server, you take away one of the barriers.
Simple to configure
Having experience with products like Splunk, Nagios, Oracle Enterprise Manager, I know these require a separate server, often with database, sometimes even agent installations, specific configuration and user management. It would require a project and specific expertise to do a solid implementation of any of those. For a simple dashboard, many of the features are overkill. For example, you do not need a history of availability if you only display the current status. If you make it available to anyone interested / run it locally, you do not need user management. This simple dashboard is configured with a single simple JSON file which gives information on an HTTP endpoint to poll and a polling interval.
In order to check connectivity and responses to certain status codes, http://httpstat.us is useful! In this case I'm monitoring 4 services. The first 3 respond with the indicated HTTP status code. Of course 500 and 400 are errors and 200 is OK. The last one, www.oracle.com was added to test with a site which does not respond with the HTTP header Access-Control-Allow-Origin. We'll get back to that later.
However
This simple dashboard seemed like a great solution to quickly implement a simple dashboard. In reality though there were some challenges.
Access to servers. Security concerns
In order to provide a single dashboard which provides a complete overview of server availability, the dashboard should have access to all different systems. This requires the dashboard to run on a machine which has access to all different servers. When the software has a server side component, it is more easy to securely configure which endpoints the monitoring software is allowed to access from which machine. When running solely from a browser, this becomes a challenge since any client could run the monitoring software.
Sharing results among clients
A simple dashboard polls different servers once in a while. If however a large amount of clients all run the simple dashboard, this can significantly increase the load on the network and the monitored systems. Results from the different clients are not shared since there is no easy way to do this without a server side component.
To help mitigate this, you could run the dashboard on a single server and provide a screen in a common room so everyone can view the dashboard.
Only basic features
The simple dashboard is a simple dashboard with basic functionality. It works well for specific HTTP requests but you will need to extent it if you want something more than it currently offers, such as database connectivity checks or actual response body checks. It is no extensive suite which has lots of features but just a simple dashboard. You could also check out the forks if someone already implemented the additional functionality you are looking for.
Cross domain requests
This is probably the most significant challenge. The dashboard runs from a browser. Browsers perform certain checks on responses, such as that if cross domain requests are performed, the response should specifically indicate the request is allowed; CORS. This however requires that the servers you are polling, send a specific header in response (Access-Control-Allow-Origin). Sometimes you are not in control of the server you are monitoring and it does not respond with this header or does not return a header with an accepted content. Result is that the browser blocks the response and the dashboard receives an error while the server response might have been valid. This behavior is similar when running the dashboard from disk or hosted by the local Node.js server. This is a challenge which you do not have when you're using a server side component which performs the requests since you are in complete control then.
You can see the errors in the Developer tools (or something called similar) which most browsers have.
How to disable cross domain checks
You can disable cross domain checks in browsers but this is specific to the browser. You should not use the browser to go online anymore since disabling security features can be dangerous. I use a separate Chrome with a specific data directory.
The challenges might not be relevant to you
Of course, the challenges are dependent on your organisation and might not be relevant to your environment. This simple-dashboard can be considered a last resort when all else fails to at least have something.
Running a dashboard solely from a browser is not a good idea
After having looked at the simple dashboard, I realized running a dashboard from a web browser is not the best thing to do.
Sharing results among clients
A simple dashboard polls different servers once in a while. If however a large amount of clients all run the simple dashboard, this can significantly increase the load on the network and the monitored systems. Results from the different clients are not shared since there is no easy way to do this without a server side component.
To help mitigate this, you could run the dashboard on a single server and provide a screen in a common room so everyone can view the dashboard.
Only basic features
The simple dashboard is a simple dashboard with basic functionality. It works well for specific HTTP requests but you will need to extent it if you want something more than it currently offers, such as database connectivity checks or actual response body checks. It is no extensive suite which has lots of features but just a simple dashboard. You could also check out the forks if someone already implemented the additional functionality you are looking for.
Cross domain requests
This is probably the most significant challenge. The dashboard runs from a browser. Browsers perform certain checks on responses, such as that if cross domain requests are performed, the response should specifically indicate the request is allowed; CORS. This however requires that the servers you are polling, send a specific header in response (Access-Control-Allow-Origin). Sometimes you are not in control of the server you are monitoring and it does not respond with this header or does not return a header with an accepted content. Result is that the browser blocks the response and the dashboard receives an error while the server response might have been valid. This behavior is similar when running the dashboard from disk or hosted by the local Node.js server. This is a challenge which you do not have when you're using a server side component which performs the requests since you are in complete control then.
You can see the errors in the Developer tools (or something called similar) which most browsers have.
How to disable cross domain checks
You can disable cross domain checks in browsers but this is specific to the browser. You should not use the browser to go online anymore since disabling security features can be dangerous. I use a separate Chrome with a specific data directory.
- Chrome / Chromium: start with --disable-web-security --user-data-dir
- Safari: Enable the developer menu, and select "Disable Cross-Origin Restrictions"
- Firefox: apparently there are plug-ins available which add headers to response messages. Have not tried them though.
- IE (don't use it!): Tools->Internet Options->Security tab, click on “Custom Level” button. Find the Miscellaneous -> Access data sources across domains setting and select “Enable” option.
The challenges might not be relevant to you
Of course, the challenges are dependent on your organisation and might not be relevant to your environment. This simple-dashboard can be considered a last resort when all else fails to at least have something.
Running a dashboard solely from a browser is not a good idea
After having looked at the simple dashboard, I realized running a dashboard from a web browser is not the best thing to do.
- Server access. You need to allow access to different servers from every client running the dashboard. This is a security risk since there can be many clients.
- Security. The responses should implement CORS since else the browser might block requests. If not all servers implement it, you can disable cross domain checking, which of course is dangerous or resort to more elaborate workarounds.
- Performance. Results cannot be shared between clients since there is no server side component. This can cause server hammering/performance issues if here are many clients.
- Limited features. A browser can only do HTTP and some other things, but for example no database availability checking if the database does not have an HTTP endpoint.
No comments:
Post a Comment