kevinslin

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.

in case folks find it helpful: https://github.com/kevinslin/safe-npm

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

and keep enough shared context between the steps so that there is coherence

nice! will check it out

same agent. just more constraints around the domain (of creating a vscode extension)

big fan of smol-developer. it provides a great starting point for doing complicated things while being simple enough to reason about :)

dalle2 with the following prompt: Humanoid robots working on putting chips together in a factory, digital art

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

As a developer working at the intersection of cloud and "fullstack" - doing software often feels like an endless chain of stack overflow queries. While this works, it also makes it hard to figure out how to "master" something when the ground feels like its constantly changing.

The compromise I've come up with is to focus on understanding the underlying concepts (things that don't change, eg. language paradigms, networking fundamentals, etc) and then develop an index to be able to quickly externalize and reference the specific implementation details (things that change, eg. js frontend frameworks).

The post here is the distillation of this in action (I'm the author). curious how other folks manage knowledge in this space and whether this resonates.

thanks for the catch. fixed on the site but unfortunately can't update the hn title

Funny enough, two years since making it, I'm still working on the one liner (creator of Dendron here).

The current one liner: dendron is an open source, developer focused note taking tool that lets you quickly find and organize your notes in vscode using flexible hierarchies.

Given a few more lines, I would add: what IDEs do for programming languages, we want to do for knowledge - that is to say, give you the tooling to manage large amounts of it using concepts like refactoring, lookup, and schemas (think of this as type definitions but for the structure of your notes)

yep

happy customer of gitjournal. also creator of a git backed open source note taking tool. we don't have a dedicated mobile app (yet) and recommend folks use gitjournal > https://blog.dendron.so/notes/fDCVPEo3guCFWPdxokXHU#gitjourn...

reminds me of the trend to containerize/micro-service/lambda things for *scale* - its usually just introduces unecessary complexity

used to work at AWS where I've worked with (and created) legacy services that failed to scale with rising usage (a good problem to have). Its not that these services were badly designed - rather, they were designed to meet the scale and constraints at a point in time. And that's okay

The future is hard to predict - so make it easy on yourself and solve the actual problems you have today vs hypothetical ones that might never materialize.

Especially in tech, by the time you do need to solve that problem, there will probably a better (serverless AI blockchain) technology that you can use to do it

you might also want to check out https://dendron.so It's like notion but for developers and embeded inside of vscode (disclaimer: I'm the founder)

The problem with externalizing information (note taking) is that past a point, it becomes difficult to find information again when you need it (because you have too much information to comb through). wrote extensively on this in [It's Not You - It's Your Knowledge Base](https://www.kevinslin.com/notes/e1455752-b052-4212-ac6e-cc05...)

I find that at the end of the day, the only thing that works over long periods of time (and a large number of notes) are hierarchies with a regular structure that can be applied consistently. The pain point with this system is that hierarchies are hard to change and the way we think of things does change. This is why I ended up creating my own note taking tool built around the idea of flexible hierarchies (https://dendron.so)

Articles like this often inspire wishful thinking (aka - if I bookmark this page or highlight its content, I know have access to all the mental models).

I find mental models like knowledge in general - useful only if you can find the relevant entry *when needed*. They're not useful if just collected on a shelf but ingrained into memory and lived as everyday live. That being said, first step of ingraining useful mental models is to write them down (hence, [my mental models](https://kevinslin.com/notes/LMpLWbLBIfRzkSjJlF7U1)).

Thanks :)