Merge pull request #1348 from input-output-hk/rename-events

Rename Event -> Input
cardano-scaling · Mar 12, 2024 · aebba20 · aebba20
2 parents 34d2890 + a04997a
commit aebba20
Show file tree

Hide file tree

Showing 30 changed files with 449 additions and 3,658 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -38,6 +38,11 @@ changes.
 
 - Add support for `Conway` in `hydra-chain-observer`.
 
+- **BREAKING** Change to the `hydra-node` logs, monitoring and removal of `log-filter` executable:
+  - We renamed the `Event` data types to `Input` and consequently log items like `BeginEvent` to `BeginInput`.
+  - In course of this, we also removed the `log-filter` executable as nobody is actively using it and we recommend using other off-the-shelf utilities to manipulate structured JSON logs (`jq` is already quite powerful).
+  - Renamed prometheus metric `hydra_head_events -> hydra_head_inputs`.
+
 ## [0.15.0] - 2024-01-18
 
 - Tested with `cardano-node 8.7.3` and `cardano-cli 8.17.0.0`.

diff --git a/docs/core-concepts/architecture/index.md b/docs/core-concepts/architecture/index.md
@@ -43,12 +43,7 @@ The Hydra node maintains an internal wallet using the Cardano signing key provid
 
 ### Head Logic
 
-This is the component which is the heart of the Hydra node, implementing the protocol's _input-output state machine_. It is structured around the concepts of `Event`s and `Effect`s:
-
-- `Event`s are _inputs_ to the state machine from various parts of the node that can change the state and they ...
-- ... produce `Effect`s which are _outputs_ from the state machine interpreted by other components to produce "side-effects".
-
-The _Head Logic_ of course maintains the internal state of the head and persists it when it changes. This state consists in both the content of the Head itself (eg. current Ledger, transactions pending) _and_ the data from the Layer 1 that's needed to observe and trigger on-chain transitions.
+This is the component which is the heart of the Hydra node, implementing the protocol's _state machine_. It is structured around the concepts of `Input`s and `Effect`s: `Input`s from the outside world are interpreted against the current state, this may result in internal `Event`s, which are aggregated into an updated state, and `Effect`s which result in "side-effects" on the outside world. The state available to the _Head Logic_ consists of both, the content of the Head itself (eg. current Ledger, transactions pending) _and_ the data from the Layer 1 that's needed to observe and trigger on-chain transitions.
 
 ### Hydra Smart Contracts
 

diff --git a/docs/docs/getting-started/operating-hydra.md b/docs/docs/getting-started/operating-hydra.md
@@ -14,12 +14,6 @@ This page aims at helping Hydra users troubleshoot issues when running their own
 
 Following [ADR-9](/adr/9) design principles, the `hydra-node` provides [JSON](https://json.org) formatted logs on the `stdout` stream, one line per log item. The log items follow a [JSON schema](https://github.com/input-output-hk/hydra/blob/master/hydra-node/json-schemas/logs.yaml). This logging capability is kept voluntarily simple and non configurable in order to ease integration of Hydra logging into more general log analysis infrastructure, whether a custom ELK stack, third-party services, docker sidecars...
 
-:::info
-
-There is an unpublished [log-filter](https://github.com/input-output-hk/hydra/blob/master/hydra-cluster/exe/log-filter/Main.hs) executable that one can attach to a hydra-node in order to trim down the volume of information in the log stream. This filter provides _some_ filtering features, namely removing transactions bodies and replacing them with transaction ids, but it's not general enough to warrant publication. Similar capabilities can be easily provided with tools like [jq](https://stedolan.github.io/jq/).
-
-:::
-
 ## Monitoring
 
 When given `--monitoring-port PORT` argument, the hydra-node executable will expose a [Prometheus](https://prometheus.io) compatible HTTP `/metrics` endpoint on the given port to enable _scraping_ of exposed metrics.
@@ -37,8 +31,8 @@ will output
 ```
 # TYPE hydra_head_confirmed_tx counter
 hydra_head_confirmed_tx  0
-# TYPE hydra_head_events counter
-hydra_head_events  50467
+# TYPE hydra_head_inputs counter
+hydra_head_inputs  50467
 # TYPE hydra_head_requested_tx counter
 hydra_head_requested_tx  0
 # TYPE hydra_head_tx_confirmation_time_ms histogram

diff --git a/hydra-cluster/exe/log-filter/Main.hs b/hydra-cluster/exe/log-filter/Main.hs
diff --git a/hydra-cluster/hydra-cluster.cabal b/hydra-cluster/hydra-cluster.cabal
@@ -73,7 +73,6 @@ library
     Hydra.Cluster.Scenarios
     Hydra.Cluster.Util
     Hydra.Generator
-    Hydra.LogFilter
     HydraNode
     Paths_hydra_cluster
 
@@ -128,20 +127,6 @@ executable hydra-cluster
   build-tool-depends: hydra-node:hydra-node
   ghc-options:        -threaded -rtsopts
 
-executable log-filter
-  import:         project-config
-  hs-source-dirs: exe/log-filter
-  main-is:        Main.hs
-  ghc-options:    -threaded -rtsopts
-  build-depends:
-    , aeson
-    , base                  >=4.7 && <5
-    , bytestring
-    , hydra-cluster
-    , hydra-node
-    , hydra-prelude
-    , optparse-applicative
-
 test-suite tests
   import:             project-config
   hs-source-dirs:     test

diff --git a/hydra-cluster/src/Hydra/LogFilter.hs b/hydra-cluster/src/Hydra/LogFilter.hs
diff --git a/hydra-cluster/test/Test/EndToEndSpec.hs b/hydra-cluster/test/Test/EndToEndSpec.hs
@@ -479,7 +479,7 @@ spec = around (showLogsOnFailure "EndToEndSpec") $ do
                     send n1 $ input "Init" []
                     void $ waitForAllMatch 3 [n1] $ headIsInitializingWith (Set.fromList [alice, bob, carol])
                     metrics <- getMetrics n1
-                    metrics `shouldSatisfy` ("hydra_head_events" `BS.isInfixOf`)
+                    metrics `shouldSatisfy` ("hydra_head_inputs" `BS.isInfixOf`)
 
     describe "hydra-node executable" $ do
       it "logs its command line arguments" $ \tracer -> do