Coin Support is a startup that provides an easy way into the new world of cryptocurrency.
Thanks to the deep technical understanding of blockchain, the company provides a comprehensive consulting service which makes their customers crypto ready and confident for their first cryptocurrency transactions.
The Coin Support website is hosted on Kubernetes infrastructure because it allows excellent scalability and ensures perfect observability. In case of an outage of some services, self-healing is built-in.
Nevertheless, also an application running on self-healing infrastructure needs monitoring. The Coin Support Team wants to be informed if there is something terrible happening on the infrastructure layer as well as the service and application layer and whenever possible from
one source of truth.
Because of the relationship between Performetriks and Coin Support, Dynatrace came to the rescue. Performetriks has longtime experience with Dynatrace and uses it a lot because it provides an easy way to integrate a single source of truth to monitor the entire software stack. The additional artificial intelligence called Davis in Dynatrace makes it easy to find the root cause of performance hotspots.
The integration was reasonably simple because Dynatrace supports a Kubernetes operator.
Summarized, the following steps were necessary: installing the operator, creating a secret holding the Environment ID and PaaS token (both can be looked-up or created in Dynatrace below the menu “Deploy Dynatrace”, “PaaS integration”), and rollout the OneAgent (done by a Kubernetes custom resource of type OneAgent). See link two below for more information.
After that, the OneAgent was installed on every Kubernetes cluster worker node, and monitor information flowed into Dynatrace. Worker node host information like operating system, memory consumption, CPU consumption, network interface information was then available.
But still, there was no information available under the dedicated Kubernetes overview page in Dynatrace. To get the full power of Dynatrace Kubernetes observabilities, an ActiveGate needs to be installed in the infrastructure environment. For this reason, we created a virtual host in our environment and installed the ActiveGate on it. That ActiveGate appeared then in Dynatrace below the menu “Deployment status”. The ActiveGate talks to the Kubernetes API to fetch additional monitoring information like Kubernetes events and cluster workloads.
This information is then available for Dynatrace via the ActiveGate. To allow the
communication from ActiveGate through the Kubernetes API a Kubernetes Service Account is necessary. Please see link 3 on how to do that. Finally, in the menu “Kubernetes” in Dynatrace we chose the created ActiveGate and provided the Kubernetes API URL and bearer token from the previously created service account to connect to the Kubernetes cluster. After a few minutes, we could see enhanced Kubernetes observability in Dynatrace.
To change the connection settings from Dynatrace to the Kubernetes API later, you can navigate to “Settings”, “Cloud and virtualization”, “Kubernetes”.
Last but not least, we've created a synthetic browser monitor to test the availability of our website. For this reason, the Chrome browser with the extension “Dynatrace Synthetic Recorder” was required. After the installation, we could record a Dynatrace clickpath. This means, we clicked all the links on our website and the plugin recorded every link click. Afterward, we selected the frequency and location from where our website should be visited for testing. Now our site is regularly called for testing. As soon as the browser monitor fails
(any HTTP status code from 400 to 599), Dynatrace generates a problem, and we’informed.
Please follow the links below for further information.
Commentaires