How to use Marathon tags to improve operational analysis capabilities
Marathon's goal is to allow users to run a variety of applications and services on the same set of servers – Hadoop, Storm, and even a standard Web application. Mesos-based human cloud uses Marathon technology to deploy and monitor long-running and containerized applications, and will be updated in the near future for future follow-up, to provide better The service.
- Deploy the Mesos cluster through the Docker
- Swarm, Fleet, Kubernetes, Mesos - Comparison of Arrangement Tools
- DC / OS key technology and application scenarios
- I have experience running Docker containers on Mesos
- Docker, Mesos and Marathon analysis and entry combat
- Docker to share (110): Docker landing in Shanghai practice
As more and more companies are turning to multi-tenant data centers or private cloud systems, operational analytics are becoming increasingly important in order to improve IT execution efficiency on new platforms. Responsible for managing data center and budget assignments of course want to know which services are running, who is responsible for their operations, and how much resources each consumes. In view of this, when we deploy an application or container on a data center operating system (DCOS) cluster, you can tag the components to track and report on their usage.
For example, you might want to assign a cost center identifier or customer number to a Mesos application, and then generate a summary report at the end of each month. This report can cover a variety of usage metrics, such as the amount of CPU and memory resources allocated by the cost center or client for the application. Further, we can also use the REST API or JSON load to interact with Splunk or Jaspersoft and other analysis tools to analyze the task data in a relaxed but powerful way.
The following look at the specific implementation:
Assign labels to applications and tasks
Marathon included in Mesosphere DCOS is used to deploy and monitor long-running and containerized applications. You can use Marathon's Web interface to implement applications for manual deployment, or use the DCOS Marathon command line interface to achieve the same effect.
Figure 1: Marathon Web interface – application 1 tag
Figure 1 shows how to use the Marathon web interface to specify a tag for a startup container or a command line application. The application shown in the name is gregs-app-1, we can see its label name COST_CENTER has been defined and set to 0001. When the application is deployed, it will collect the cost center values associated with itself and allow the administrator to query through the Marathon REST API.
Figure 2 shows the second application using the Marathon Web interface, but this time its COST_CENTER tag is set to 0002. This tag and value will be displayed in the Marathon web interface and will be returned via the REST API call.
Figure 2: Web interface – application 2 tags
You can also use the DCOS collaboration line interface to deploy the application, through the following way to specify the label value:
dcos marathon app add <my json file>
Figure 3 shows the JSON format used by the DCOS command to deploy the application through Marathon. As with the Marathon web interface, you can also specify more than one tag for it, but each tag can only have one value.
Figure 3: Apply 2 Marathon JSON files
Display label information
Now that the application has been deployed and running, you can use the Marathon Web interface provided by DCOS to see the running status of both applications through the relevant tab. Figure 4 shows the two applications in the display of its COST_CENTER label value when the operation results.
Figure 4: Marathon Web interface – running the application
You can also use the Marathon REST API to query running applications based on tag values. Figure 5 shows a REST request to a Marathon service running within a Mesos cluster. In this example, the curl program is used to commit HTTP GET requests, but you can also use any program that can send HTTP GET / PUT / DELETE requests to achieve the same functionality. We can see that its REST endpoint is:
The parameters sent by REST request contain the following criteria:
Figure 5: Marathon REST API usage
You can also specify multiple label criteria at the same time:
When Marathon receives an HTTP GET request, it responds with a JSON payload. JSON is not easy to read in the design, but if you use the python json.tool class and other tools, you can format it to adjust, in order to achieve a certain degree of readability. In a set of actual production systems, we should also have the ability to decode JSON format response data to a readable format (or chart) of the reporting tool. However, in this example, let's just look at the original output of JSON.
As you can see, the response message contains only the application whose label is defined as COST_CENTER and has a correlation value of 0001. Its related resource indicators are also included, such as the number of CPU shares and memory allocation. At the bottom of the response information, we can see the deployment date / time of the application, which can be used to calculate the application's uptime, to check the resource expense account or refund.
to sum up
By running applications or containerized services on top of DCOS and Marathon, we are able to track cluster usage for billing or refund. Looking to the future, this capability will become increasingly important as more and more companies begin to deploy private clouds, multi-tenant data centers, and containerized workloads to cut resource costs and improve operational efficiency. It is really commendable to take the sharing of resources in the application's work, but our goal is to make the resource sharing mechanism better and more realistic.