Go to All Forums

list of Things what are required for automation

Hi Site24x7 Team,
 
as mentioned in other threads we are more and more increasing our footprint at AWS. We deploy on an daily bases EC2, RDS and ELBs in different Regions and multiple AWS Accounts. Currently we use the following Features of Site24x7:
 
1) Auto-Discovery by Site24x7 RO AWS User for multiple Accounts with Threshold / Monitoring of RDS, EC2 and ELBs.
2) Installation of Site24x7 Linux & Windows Server Agents
3) development of our own plugins and related them to the Server Agents 
4) End2End Measurements by Website Monitors
5) End2End Transaction Checks by RealBrowser Measurements
6) development of our own Actions to react on status changes
 
For us is Automation key - and API is King! That means, for Installation, Updates and Configuration, we need simply an comprehensive solution, what enables us to use the API instead of an GUI like the Web interface of Site24x7.  Everytime when we need to interactively use the GUI, we do act as an human bottleneck. Imagine, it takes us just an trigger to deploy let's say 100 Servers in multiple regions. The deployment itself is done after 10 Minutes. Now imagine, we would need to configure the site24x7 Monitor for every single Server Monitor via the GUI. Thats just an overkill.
 
So, therefore I would like to ask you to pick up the following feature request to support the comprehensive API support. I am pretty sure, that's an invest in the future and let your customers like us scale with site24x7 as we can scale out with the cloud.
 
1) SERVER AGENT
 
a) Monitoring ID:
it is really required, that the monitoring_id is available immediately on the local machine (where the agent has been installed) after the Agent has been installed. Today we need to download the whole list of all monitors from the API and seek for the just installed Agent. That is horribly error prone. Please add an feature to your agent, that it will get it's own Monitoring_ID and store it anywhere in the local file system (like /opt/site24x7/monagent/monitoringid.txt) or export the ID to the env variables.
 
b) Process monitoring / custom configuration template:
It is absolutely mission crucial to add specific processes to the measurement. Right now it is just possible via the GUI. Please update the API that we can add/modify/remove Processes to the SERVER Agent measurements
 
 
c) Version Control / Update Agent feature:
It would be helpful to get an overview of the different and current versions of the site24x7 server agents installed out there in the field. Even better, each Server monitor should have this version as string, readable via the API. It would be furthermore helpful to be able to trigger the update of all / list of agents remotely, by just an API trigger.
 
 
 
2) OTHER
 
a) support customer owned BulkSMS
We like that you support 3rd endpoints for alarms like Slack. Even better would be, if we could use our own enterprise BulkSMS Account instead of the Site24x7 SMS. Today we use for that purpose the ACTIONS, but a transparent integration in the userprofile would be better and less error prone.
 
 
b) SSO with an 3rd Party IDP
With growing teams, especially of different vendors and companies, it would be cool if an 3rd Party IDP like OKTA would be supported. 
 
c) AWS API calls with Site24x7 ACTIONS 
It would be very cool, especially for BCM tasks, to trigger AWS API calls via the Site24x7 ACTIONs (e.g. like http://docs.aws.amazon.com/AWSEC2/latest/APIReference/making-api-requests.html
 
d) Published Reports, periods adjustable by the viewer
We predefine a lot of Reports and Status Pages. However, it is quiet sad that we have to define an fixed period before we create the URL of the Report to share with our clients. It would be much better, if we could share an Report, and the actually viewer of the published report link could adjust by and switch the period, let's say today, last week, this year etc pp..
 
So, thats for now what would really improve from our point of view the already excellent portfolio of your Monitoring SaaS. Keep going folks, you are doing a great job. 
 
 
cheers
Markus
Like (4) Reply
Replies (5)

Re: list of Things what are required for automation

May I ask for some Feedback please, thanks a lot.
Like (0) Reply

Re: list of Things what are required for automation

site24x7 team,

not any tiny response at all? Seriously? Thats actually quiet sad.

best regards
Markus
Like (1) Edit Delete Reply

Re: list of Things what are required for automation

Hello Markus,

Sorry for not responding at the earliest.  I will get back on this by tomorrow.

Raghavan
Like (0) Reply

Re: list of Things what are required for automation

After a whole week after my initial post, still no real feedback from Site24x7 Team.

When I met you guys at the re:invent 2016 in Vegas we had actually the same discussions as mentioned in my post... my impression was back that time, that you are actually follow the idea of AWS and automate everything. 

Shall we just give up? Is this the way to handle it? 

cheers
Markus



Like (1) Edit Delete Reply

Re: list of Things what are required for automation

Hi Markus,
 
We are very sorry for this late response to your post. 
 
Thanks for the detailed requirements you had given.  Please find my response for each of those questions below:
 
SERVER AGENT
 
a) Monitoring ID:
 
Currently we allow parameters like Display Name to be passed from the command line installation process of the server agent and allow to retrieve monitor information via API using the Display Name. You can utilize this process to identify the monitor id automatically and do actions over this. 

Help documentation for command line mode is available in the below link:
 
API documentation to retrieve the monitor information using Display Name is not documented, however you can use it as detailed below:
GET /api/monitors/name/{monitor_display_name}
Monitor display name should be in URL encoded format. 
ex: /api/monitors/name/My Monitor
This api will throw error when Display Name is not unique.
We will also do enhancement to this process and store the monitor id in the server itself.
 
b) Process monitoring / custom configuration template:
 
As stated above the configuration template can be set to a server agent from command line itself. 
 
For add/update/delete process, currently we don?t have exposed API. We will do this and share it here once available. 
 
For now,  you can setup default configuration template from GUI with list of processes to be added to the monitor.  This will be setup for all new Server Monitors added. 
 
 
We will provide option to add Processes to be monitored via API soon.
 
c) Version Control / Update Agent feature:
 
You can use current_status by Monitor Type api to get all the server monitors with the appropriate agent versions:
 
GET /api/current_status/type/SERVER
 
server_version parameter will give the current agent version
 
To trigger upgrade of agents use the below API
 
PUT /api/monitors/bulk_action 
 
Request Body:  {"monitors":["<monitorids comma separated>"],"bulk_action_type":9}
 
 
 
OTHERS
 
a) support customer owned BulkSMS
 
Currently it is a least priority for us as there is a work around to achieve this through Actions is already available. We are also building a custom Web Hook options in our Thirdparty integrations with ability to call internet/ intranet url?s. And it will also support any RESTful API web hooks  with OAuth support.
 
b) SSO with an 3rd Party IDP
 
Site24x7 uses Zoho Accounts for Identity Management. Zoho Accounts supports SAML authentication using which you can use can get support for OKTA IDP. For more information please visit the below link:
One another Forum post discuss on this: https://forums.site24x7.com/topic/saml-sso
 
c) AWS API calls with Site24x7 ACTIONS 
 
It is a good suggestion, we will include it in our Road Map. The referred website has many actions that can be performed. Do you have any preference on which would you use more commonly and why ? This will help us to provide some useful integration to start with.
 
d) Published Reports, periods adjustable by the viewer
 
We will look into the feasibility on supporting this feature for all public reports.
 
 
Raghavan
Like (0) Reply

Was this post helpful?