Grafana seems to be an option? Handles metrics, logs and traces. I don't know what storage costs look like though if you are self hosting.. https://grafana.com/
1,760 karma · joined July 6, 2008
Despite having to managed TBs of logs per day and sift through them at times, I'd rather have too much logs. However, we did not alert on any of them. All alerting was symptoms based via SLOs (error rate, latency). Logs were only used for debugging.
Almost 20 years of experience at great large & small companies in the SF Bay Area. I like to think that I'm relatively intelligent and competent, but man, some of the interviews were torture. Even interviews for what are mostly CRUD web app development positions were doing l33tcode interviews (literally, I googled them afterwards) of moderate CS algorithms.
After 2 months of interviews I did get 3 offers at the same time. I've interviewed around here since ~2005 and I have to say it's still a crap shoot of if you'll get a good interview process. Some companies were great and had well rounded modules, focused on leadership, communication, design and just a little bit of programming. Others threw multiple l33tcode puzzles at you and had no idea what they really needed. Very frustrating.
I think large companies with low friction are the exception, not the rule. It takes MASSIVE amounts of work to build the infrastructure that thousands of engineers need (or be willing to spend millions of dollars for SaaS). I can think of only a few large tech companies with low friction (Google, Netflix, Meta), and they spend a lot on tooling.
There's a few ways to deal with it. What I noticed was that the 'effective' engineers would avoid the standard process and be 'noisy'. They were comfortable asking directly via chat or in person for what they wanted instead of filing tickets or having meetings. They used their relationships (which they did work to build) to skip the line and save time.
You also need some kind of perspective change at large companies. You've moved from rowing your own boat to a battleship. Process is there for protection from rogue employees wreaking havoc on the system, not to make you move fast. Think of it from a manager or platform team's perspective. How do you manage over 1,000 SSL certs (and renew them)? Prevent VM proliferation that needs to be accounted for and secured? Certainly it can all be automated, but at a BigCo's scale, that is a 4-5 person job, and that team is competing with other 'revenue generating' teams for headcount.
I would also recommend to give it some time. You will adjust and learn over time how to work more effectively. I noticed after a few years that I could grease the wheels a bit because I had spent time cultivating relationships with various teams.
Good luck!
Looking for a hands-on full stack engineering leadership role. I've worked on everything from dashboards for displaying race car telemetry to database tuning to being a SRE and running major incident responses.
Location: Mountain View, CA Remote: Depends on company/role Willing to relocate: No Technologies: Ruby/Rails, Python, JavaScript, SQL, Bash, some Go Résumé/CV: https://www.linkedin.com/in/ryan-d-doherty/ Email: ryan.doherty@gmail.com
I was inspired by https://explain.depesz.com/ which is for PostgreSQL (MySQL's output does work too) but wanted to do a little side project so I whipped up a MVP.
Feedback welcome :)
* There are no solutions, just tradeoffs. Don't think there's a perfect tech stack.
* Done is better than perfect. Velocity matters. This generally means pick something you know if delivery is important.
* Boring tech tends to be reliable. Things like PHP, Rails, Django, etc. These tools have been around a long time and ironed out the kinks. Lots of documentation and tooling to make your life easier. Odds are very low your new fancy idea has any requirements that boring tech can't deliver on. This counts for every layer of the stack (frontend, DB, OS, etc).
I think the most important thing to keep in mind is you'll never have a perfect solution and that's ok! Don't get fooled by all the hype from new technologies that try to make you feel inferior for using other tech.
There's a myriad of tools out there for profiling, some language specific, some not. Learn at least one of them well, how to read flamegraphs and how to benchmark properly (warmup code, synthetic vs real traffic, etc). There's definitely a jump between making guesses and hoping you improve performance vs truly understanding what your code is doing.
Huge, beastly trucks are a status symbol and signalling to others that you are are certain demographic. Same reason some people buy cheap cars and add shiny wheels and lights. Same reason some people buy BMWs and Mercedes. These are all part of socioeconomic norms. I don't see how the normal truck crowd will latch on to this.
The specs are pretty impressive though. 500 mile range got my attention.
1: https://www.amazon.com/Field-Guide-Understanding-Human-Error...
I've installed Ubuntu 18 with 0 problems. Sleep works fine, haven't had any issues with wake up. You do need to install some custom software and change a BIOS setting for it to use 'Linux' sleep mode (or something like that). Battery life is 'pretty good', not exceptional like MBPs, but definitely in the 6hr range.
Overall I'd recommend a X1 Carbon, especially since you will spend nearly $1k less on the comparable specs.
Anyone know what those signals are? A lot of 'end is nigh' articles I've read have more details. Is it just too much growth in the stock market? Debt? Speculation?
A talk from the 'future' about how everything became 'YavaScript'.
We do not have a space or money problem, we have a legislative one. Building height limits, NIMBYs and other laws affect how many homes are built. We have plenty of space in the sky to build 12+ story buildings for housing, but we don't.
Mazda is an interesting car company. Example: they have 0 electric or hybrid cars and don't have plans to make any afaik. They have a new 'X-Active' gasoline engine that also runs like a diesel at times to gain efficiency and power (https://jalopnik.com/mazdas-upcoming-skyactive-x-compression...). I'm not sure it's a great idea to continue working on gasoline engine technology considering the industry and market, but it is impressive engineering.
They've also managed to keep the Mazda Miata at nearly the same weight (only 300lbs more than the original) and size (3 inches wider, 1 inch shorter) after over 20 years of safety and convenience improvements. I can't think of any other car model that's done that.
Somehow this small car company always punches above its weight, which is impressive.
Need a bigger database? Just a few Heroku CLI commands. Bigger web servers? 2 clicks. Want a test database to run queries against? 1 Heroku CLI command. Want to test a branch of your code against the staging database? Automatically done via GitHub PRs, with DNS setup too.
We had 0 downtime in a year due to actual Heroku issues, developers could push code easily (git push), databases were backed up automatically, servers auto-scaled, etc.
I was genuinely amazed at how well it all worked. The amount of operations work was easily 10x less than if we had to run our own infrastructure on AWS due to not just the hosting, but the tooling. Deployment, rollbacks, slave database setup, configuration management, access control, log aggregation, 3rd party integrations and more.
Heroku does have some drawbacks, request queuing is one of them, mostly due to lack of clear docs and information. Even with its flaws it still saves a massive amount of time and money. For nearly all startups to medium sized companies I'd highly recommend using Heroku.
While there isn't much reviewing going on, I've found it useful to poke through a few other submissions for exercises (especially the ones with comments). I've learned a few things from other users' code.