hi kgeist - i work on the team that manages the github app. are you able to share a conversation where the github connector did not work? feel to message me at https://x.com/kevins8 (dm's open)
as someone that likes the npm package ecosystem but is not fond of malware - ended up building a CLI wrapper around npm to only install packages older than a configurable amount of days.
snarky part of me wants to say that X not Y is a trope that has been over used by people trying to peddle their own thing that is just a thin veneer of what was there before
but it’s easy to be a pessimist and pull down other work
i agree that goals are hard and in some sense, set people up to fail by making the target some ephemeral thing in the distance
maybe reframing it as a quest can help
it’s something that can be hard
it can change you
the outcome might be different from what you intended
by all means. do quests. not goals.
will go back to nike on this one. just do it
> You can't reference your contracted volume rates when building monitors out and the units for the metrics you need to watch don't match the units you contract with them on the SKU.
Are you referring to the `datadog.estimated_usage.logs.ingested_events` metric? It includes excluded events by default but you can get to your indexed volume by excluding excluded logs. `sum:datadog.estimated_usage.logs.ingested_events{datadog_index:*,datadog_is_excluded:false}.as_count()`
For datadog, unfortunately there's no obvious altnernative despite many companies trying to take marketshare. This is to say, datadog both has second to none DX and a wide breadth of services.
Grafana Labs comes closest in terms of breadth but their DX is abysmal (I say this as a heavy grafana/prometheus user)
Same comments about new relic though they have better dx than grafana.
Chronosphere has some nice DX around prometheus based metrics but lack the full product suite.
I could go on but essentially, all vendors either lack breadth, DX, or both.
the way I think of datadog is that datadog it provides a second to none DX combined with a wide suite of product offerings that is good enough for most companies most of the time. does it have opaque pricing that can be 100x more expensive than alternatives? absolutely! will people continue to use it? yes!
something to keep in mind is that most companies are not like the folks in this thread. they might not have the expertise, time or bandwidth to build invest in observability.
the vast majority of companies just want something that basically works and doesn’t take a lot of training to use.
I think of Datadog as the Apple of observability vendors - it doesn’t offer everything and there are real limitations (and price tags) for more precise use cases but in the general case, it just works (especially if you stay within its ecosystem)
In terms of Datadog - the per host pricing on infrastructure in a k8/microservices world is perhaps the most egregious of pricing models across all datadog services. Triply true if you use spot instances for short lived workloads.
For folks running k8 at any sort of scale, I generally recommend aggregating metrics BEFORE sending them to datadog, either on a per deployment or per cluster level. Individual host metrics tend to also matter less once you have a large fleet.
You can use opensource tools like veneur (https://github.com/stripe/veneur) to do this. And if you don't want to set this up yourself, third party services like Nimbus (https://nimbus.dev/) can do this for you automatically (note that this is currently a preview feature). Disclaimer also that I'm the founder of Nimbus (we help companies cut datadog costs by over 60%) and have a dog in this fight.
Author here. Spent far too much time staring at spreadsheets in my living room calculating observability costs across different vendors and decided to write a post about it.
This is my attempt to create a common model for thinking about usage based pricing across all the vendors and (make a best effort attempt) normalize and compare the actual cost of usage.
If you have any questions or comments, would love to hear them.
author of the post here - was inspired to write this post after working with OTEL for a few months - realized that OTEL had a ridiculously large surface area that most people (at least myself) might not be aware of
I see a lot of comments about how overly complex OTEL is. I don't disagree with this. in some sense, OTEL is very much the k8 for observability (good and bad)
The good is that it is a standard that can support every conceivable use case and has wide industry adoption
The bad is that there is inherent complexity in needing to support the wide array of use cases
I realize that a fair answer is "no - you shouldn't be doing that" but like .env files, I find that its a widespread practice. Curious if others have managed a way of dealing with it besides hope someone in the room has tribal knowledge of what metrics have become system dependencies
author here. wrote this article to highlight the ridiculously wide spectrum of log costs. depending on your implementation, you can be either absurdly expensive or astoundingly cheap. cloudwatch logs is unfortunately on the wrong end of that spectrum. happy to answer any followups
author here. aws released amazon cloudwatch logs live tail (it is a mouthful) earlier this month. it enables 'real time' tailing of cw logs. given that cw logs has 5s-20s latency for ingestion, I was curious whether live tail made this better. ended up as a blog post
tldr: live tail is downstream of cloudwatch logs so you still have the same initial delay in first getting metrics. any logs, once ingested, will be pushed to live tail in ~2s. live tail uses websockets under the hood and is a console-first feature - there is no API
amen to that. working with cloud infrastructure is like working with 2020 machines using assembly. there is a large, and growing, disconnect between the power of the hardware and expressivity of the underlying language used to unlock it
Author here. Happy to answer any questions or comments.
As a teaser for a followup: I've been able to create a version of this that is able to generate an extension in one shot without any issues. This is done by giving GPT more context on the expected project layout as well as a checklist of constraints in order to create a valid app. Its not hard to envision a future where all software projects can be scaffolded by a LLM
Hey All, author here. AWS Doc Extractor clones all github aws docs and finds all *Note-able* admonitions (as well as Important, Considerations, etc) and compiles it all in one place. It is then published as a gitbook at (https://awsnotes.dendron.so).
This project exists because I observed that any section of the AWS docs that start with a *Note* was something that was worth paying attention to. These sections documented gotchas, limits, and other caveats of a particular service. When not observed, they can take anywhere on the order of hours to weeks to work around.
Ironically, AWS has made an announcement yesterday to retire the github docs (https://aws.amazon.com/blogs/aws/retiring-the-aws-documentat...) which means I'll need to invest in adding a page scraping component to this project after June to keep docs up to date