Tbh, I was thinking, if we are planning to use DataDog agents, then this would be a lot of duplication of work (at least in terms of telemetry signal generation). Maybe, there’s a tool that just does what’s needed (testing in this case).
Our choice of visualization for cloud is fixed at large scale (except for testing purposes).
DataDog Hell
Data collection or generation segment is separated from the Visualization segment.
And hence ending up in a question of which visualization do I pick, when I am moving to cloud, but need a tool that was built on-premises, but would cost more with the cloud based strategic solution of choice – DataDog (costs more for transmission of data to the DataDog server as all of the telemetry signals that our testing suite has generated would be treated as custom metrics and would not be included in the subscription we have that otherwise “generates” and transmits the signals for no additional charges on top of the base subscription charges).
Sometimes it looks like these type of cross roads are reached at, knowingly or is a part of the journey of migration to cloud. Because, we already had the internal tooling that gave testing and telemetry signal generation.
While the new tool of choice comes with its own generation and collection.
Charging more on transmissions not originating from their data generation sources.
The DataDog Agent.
I feel it’s a greedy move or incapability of DataDog to not cater to all the incoming sources of telemetry data with a few specifications being met for the sanity and integrity of the data. In a way, this looks like DataDog being less confident in its integration with third parties. When they are giving you the data, all you have to do is, use it, instead of getting comfortable with generating the data all by yourself.
Makes DataDog more viable a tool that way, opening more doors to a new client base.
Instead of holding back and thinking that it could bring in competition. The owner of DataDog only eats one meal per day. And no loss in life from here should deprive them of the capability of earning a meal when in need. If that can happen, then there is something terribly wrong in what they have done.
Why charge more for data that’s not generated by the DataDog agent? Are you trying to tell us that your processing charges are variable based on how much the data is away from what DataDog calls data?
If so set specifications for your integrating entities to format it in a specific way.
Instead of that, charging more for the data that’s already available and is being generated by the system DataDog is trying to help monitor. It’s like, I am selling eyes. But my eyes don’t come without brain. And I know that you have brain already and only need eyes to see. But you have to pay me for my brain too. While you have already paid for my brain through your subscription, additionally. As I do not know what, I would have to process. Because, if I generated the data then I do not have surprises in giving you the results you require.
But, the funny part is, we already know that DataDog has the capability to understand our custom data too and process it for us. But that’s sold as a feature. Instead of a branching statement.
Which is too greedy of DataDog, I feel.
Nah DataDog, you can do more than this.
Open Telemetry or DataDog?
Thoughts Flow 