logging   23062

« earlier    

Peter Bourgon · Logging v. instrumentation
In my opinion, my thesis from GopherCon 2014 still holds: services should only log actionable information. That includes serious, panic-level errors that need to be consumed by humans, or structured data that needs to be consumed by machines. An example of the former would be a message signaling that a required database has become completely unavailable. An example of the latter would be a message indicating a media object has been played, recorded so an end-of-day batch process might calculate owed royalties. Logs read by humans should be sparse, ideally silent if nothing is going wrong. Logs read by machines should be well-defined, ideally with a versioned schema.

Instrumentation is for all remaining diagnostic information about your service. In contrast to logging, services should instrument every meaningful number available for capture. Metrics are (or should be) cheap to record and report, and instrumentation systems are more useful the more data they contain, which is a virtuous cycle: the more you have, the better-off you are.
logging  bestpractices  instrumentation  monitoring 
5 days ago by cdzombak
The Twelve-Factor App
I. Codebase
One codebase tracked in revision control, many deploys

II. Dependencies
Explicitly declare and isolate dependencies

III. Config
Store config in the environment

IV. Backing services
Treat backing services as attached resources

V. Build, release, run
Strictly separate build and run stages

VI. Processes
Execute the app as one or more stateless processes

VII. Port binding
Export services via port binding

VIII. Concurrency
Scale out via the process model

IX. Disposability
Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity
Keep development, staging, and production as similar as possible

XI. Logs
Treat logs as event streams

XII. Admin processes
Run admin/management tasks as one-off processes
12factor  software_architecture  bestpractices  logging  deployment 
5 days ago by cdzombak
Peter Bourgon · Go best practices, six years in
The Top Tips:

1. Put $GOPATH/bin in your $PATH, so installed binaries are easily accessible.
2. Put library code under a pkg/ subdirectory. Put binaries under a cmd/ subdirectory.
3. Always use fully-qualified import paths. Never use relative imports.  
4. Defer to Andrew Gerrand’s naming conventions.  
5. Only func main has the right to decide which flags are available to the user.  
6. Use struct literal initialization to avoid invalid intermediate state.  
7. Avoid nil checks via default no-op implementations.  
8. Make the zero value useful, especially in config objects.  
9. Make dependencies explicit!  
10. Loggers are dependencies, just like references to other components, database handles, commandline flags, etc.  
11. Use many small interfaces to model dependencies.  
12. Tests only need to test the thing being tested.  
13. Use a top tool to vendor dependencies for your binary.  
14. Libraries should never vendor their dependencies.  
15. Prefer go install to go build.  

Go has always been a conservative language, and its maturity has brought relatively few surprises and effectively no major changes. Consequently, and predictably, the community also hasn’t dramatically shifted its stances on what’s considered best practice. Instead, we’ve seen a reification of tropes and proverbs that were reasonably well-known in the early years, and a gradual movement “up the stack” as design patterns, libraries, and program structures are explored and transformed into idiomatic Go.
golang  bestpractices  dependencies  dependency-injection  nil  logging  testing  dependency_management 
5 days ago by cdzombak

« earlier    

related tags

$check_out_for_sure  $tag_more  12factor  activity  admin  alert  amazon  analytics  angularjs  ansible  apache  api  apis  apps  architecture  article  awesome  aws  awslogs  balancing  bash  best-practices  bestpractices  blog  c#  c++  cassandra  ccj  cli  client  cloud  cloudwatch  configuration  configure  console  crash  cross-platform  dashboard  db  debug  debugging  departmentofjustice  dependencies  dependency-injection  dependency_management  deployment  design  dev  developer  development  device  devops  disruptj20  distributed  dns  docker  documentation  dotnet  dpi  dreamhost  easy  ec2  eca  ecs  edgemax  edgerouter  elasticsearch  eld  electronic  elk  eloquent  engine  error  error_logging  errors  events  example  exception  floss  framework  functional-programming  g1  gc  github  go  golang  greylit  guide  guis  handlers  haskell  history  howto  hynek  ifttt  instrumentation  interception  interface  ios  java  jboss  jvm  kafka  kubernetes  laravel  lb  library  linux  loadbalancing  log  log4j  log4net  logback  logger  loggers  loggly  logog  logs  logspout  logstash  mac  managmement  metrics  microservices  mobx  monads  monitor  monitoring  motor  native  network  nginx  nil  ocaml  old  oop  opensource  ops  osx  papertrail  performance  php  png  pocket  policing  presentations  pricey  programming  protest  python  rails  react-native  react  reactnative  reference  route  ruby  rust  s3  scaling  seq  server  setup  shell  side  software-design  software_architecture  softwaredevelopment  spark  speed  springboot  stackexchange  stackoverflow  stacktrace  status  structured  test  testing  tests  timemanagement  tips  tolearn  tool  tools  toread  totry  tounderstand  tracing  truck  tutorial  ulimit  unix  usa  versioning  visualization  vue.js  web  webapi  wish-list  work  wr   

Copy this bookmark: