Ruby & Rails

Install the sixty agent in this Ruby application so its controllers, service
objects and database queries report to sixty.

1. Add the gem to the main group of the Gemfile — not to :development and not
   to :test. It runs in production; that is the entire point. It has no
   dependencies of its own, so nothing else in the lockfile moves.

      gem 'sixty'

   Then bundle install.

2. Rails needs no further wiring. The railtie adds the middleware, subscribes
   to sql.active_record and wraps controller actions on boot. Do NOT write an
   initializer that calls Sixty.init — in a Rails app that is a second boot
   path for the same thing.

   If this is Sinatra, Hanami, a bare Rack app or a non-web process, then and
   only then do it by hand: require 'sixty' and call Sixty.init at startup,
   and add "use Sixty::Instrument::Rack" to config.ru.

3. Measure the layer between the controller and the database. This is the step
   the install exists for: without it the feed has routes and SQL and nothing
   in between, and an N+1 can be seen but not attributed to the object that
   causes it. In a Rails app that object is a query object, a service object,
   a serializer or a job — rarely the controller.

      class OrdersQuery
        include Sixty::Instrumented
      end

   Every public instance method of that class becomes an operation, with its
   queries and rows attributed to it. Private methods and plain accessors are
   skipped. Add it to the few classes that do real work per request — not to
   models, and not to anything called in a tight loop.

   For a class you do not own: Sixty.instrument(Stripe::Charge, :create)
   For a block: Sixty.trace('nightly-reconciliation') { ... }

4. Set these environment variables wherever the application is deployed:
      SIXTY_API_KEY  = a secret key starting sixty_sk_ — ask me for it. Do not
                       invent one, and do not commit it.
      SIXTY_SERVICE  = my-app
      SIXTY_ENDPOINT = https://ingest.sixty.sh

   The release identifier is picked up automatically on Vercel, Render,
   Railway, Fly, Heroku and GitHub Actions. If this deploys some other way,
   set SIXTY_RELEASE to the commit SHA — without one, every measurement lands
   in a single nameless bucket and no comparison can ever be made.

Constraints — correctness requirements, not style preferences:

- Do NOT change any application behaviour. This is instrumentation only: no
  refactors, no reordering of business logic, no "while I was in here" fixes.
- Do NOT include Sixty::Instrumented in ActiveRecord models or in anything
  called per row. A span costs a few microseconds, which is nothing next to a
  request and everything next to a loop over a result set.
- Do NOT add any analytics, user id, session id, or cookie to what is
  reported. The agent is deliberately anonymous and must stay that way.
- Leave the database configuration alone. pg, mysql2, trilogy and mongo are
  all instrumented already; if this application reaches its database some
  other way, tell me rather than wiring something up.

If this runs under Puma with workers, or under Sidekiq, note how many
processes it runs: each reports independently and the collector merges them,
which is correct, but it is worth knowing when you read the numbers.

When you are done, tell me which files you changed, so I can confirm data is
arriving.