Datadog

We just launched the Segment Config API (try it out for yourself here) — a set of public REST APIs that enable you to manage your Segment configuration. Behind the scenes the Config API is built with Go , GRPC and Envoy.

At Segment, we build new services in Go by default. The language is simple so new team members quickly ramp up on a codebase. The tool chain is fast so developers get immediate feedback when they break code, tests or integrations with other systems. The runtime is fast so it performs great at scale.

For the newest round of APIs we adopted the GRPC service #framework.

The Protocol Buffer service definition language makes it easy to design type-safe and consistent APIs, thanks to ecosystem tools like the Google API Design Guide for API standards, uber/prototool for formatting and linting .protos and lyft/protoc-gen-validate for defining field validations, and grpc-gateway for defining REST mapping.

With a well designed .proto, its easy to generate a Go server interface and a TypeScript client, providing type-safe RPC between languages.

For the API gateway and RPC we adopted the Envoy service proxy.

The internet-facing segmentapis.com endpoint is an Envoy front proxy that rate-limits and authenticates every request. It then transcodes a #REST / #JSON request to an upstream GRPC request. The upstream GRPC servers are running an Envoy sidecar configured for Datadog stats.

The result is API #security , #reliability and consistent #observability through Envoy configuration, not code.

We experimented with Swagger service definitions, but the spec is sprawling and the generated clients and server stubs leave a lot to be desired. GRPC and .proto and the Go implementation feels better designed and implemented. Thanks to the GRPC tooling and ecosystem you can generate Swagger from .protos, but it’s effectively impossible to go the other way.

Which #APM / #Infrastructure #Monitoring solution to use?

The 2 major players in that space are New Relic and Datadog Both are very comparable in terms of pricing, capabilities (Datadog recently introduced APM as well).

In our use case, keeping the number of tools minimal was a major selection criteria.

As we were already using #NewRelic, my recommendation was to move to the pro tier so we would benefit from advanced APM features, synthetics, mobile & infrastructure monitoring. And gain 360 degree view of our infrastructure.

Few things I liked about New Relic: - Mobile App and push notificatin - Ease of setting up new alerts - Being notified via email and push notifications without requiring another alerting 3rd party solution

I've certainly seen use cases where NewRelic can also be used as an input data source for Datadog. Therefore depending on your use case, it might also be worth evaluating a joint usage of both solutions.

One of the very first tools I pulled in when I joined MachineShop was Datadog. We were lacking monitoring and Datadog was my go-to and in the subsequent years its thoroughly proven itself as reliable and informative. We use Datadog to both detect a wide variety of system anomalies and errors as well as provide highly detailed dashboards that help to indicate our system's health at a glance.

#Datadog #Relay42 #Monitoring

With Datadog unveiling their Synthetics product (https://www.datadoghq.com/blog/introducing-synthetic-monitoring/), we at Relay42 are considering moving out of Pingdom.

The rationale is simple:

• 90% of our monitoring is on Datadog, apart from the external requests. It'd be nice to identify regional issues in one place, so this is great in our monitoring consolidation efforts.

• The lack of a non-community Terraform provider for Pingdom

We have yet to get in the beta and test it out but we feel very excited about this announcement.

Powerful all-in-one monitoring solution as a service. Good integration with AWS. Very affordable price for small-scale startups. Datadog

Monitors things like server cpu/memory/disk usage and sends Runbook a webhook when things get out of wack. Datadog