[ https://issues.apache.org/jira/browse/HADOOP-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15825927#comment-15825927 ]
Steve Loughran commented on HADOOP-13453: ----------------------------------------- They're going to have to go into that file because those are the metrics published by the S3A filesystem when deployed, returned by S3AStorageStatistics in a call to {{S3AFileSystem.getStorageStatistics(), and printed in {{S3AFileSystem.toString()}}. We could choose whether to add the specific metrics to every S3a FS instance; that's something to consider. Listing the values but returning 0 for all gauges and counters is the most consistent. Don't worry about the class length: if you look at it in detail, there's two nested classes + support methods explicitly for output/input streams...you don't need to go there. The rest of the code is fairly simple # add new values to org.apache.hadoop.fs.s3a.Statistic; prefix {{s3guard_}} # In {{S3AInstrumentation}}, add counters to the array {{COUNTERS_TO_CREATE}}; gauges to {{GAUGES_TO_CREATE}} # Pass in an instance of the instrumentation down to S3Guard # have the code call incrementCounter and increment/decrementGauge as appropriate # I'd like a simple counter of {{s3guard_enabled}} and {{s3guard_authoritative}}, which will be 0 when there's no s3guard running, 1 when the respective booleans are up. Why? Remote visibility You make a good point, "where are the tests?". The answer is: the metrics can be used to test the internal state of the S3 classes, therefore become implicitly tested there. Take a look at {{ITestS3ADirectoryPerformance}} for a key example of this: our test cases use the counters of the various HTTP operations as the means to verify that API calls work as expected. (note that s3guard, by reducing these, has complicated the tests) That is, you verify the counters work by asserting that they change as you make operations to the DFS. see: http://steveloughran.blogspot.co.uk/2016/04/distributed-testing-making-use-of.html for more of my thinking here bq. Sorry for the basic question, i'm really new for work on Hadoop code base. happy to explain my reasoning. We've all started off staring at a vast amount of code that we don't understand; there are still big bits of Hadoop that I don't go near. > S3Guard: Instrument new functionality with Hadoop metrics. > ---------------------------------------------------------- > > Key: HADOOP-13453 > URL: https://issues.apache.org/jira/browse/HADOOP-13453 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 > Reporter: Chris Nauroth > Assignee: Ai Deng > > Provide Hadoop metrics showing operational details of the S3Guard > implementation. > The metrics will be implemented in this ticket: > ● S3GuardRechecksNthPercentileLatency (MutableQuantiles) Percentile time > spent > in rechecks attempting to achieve consistency. Repeated for multiple > percentile values > of N. This metric is an indicator of the additional latency cost of running > S3A with > S3Guard. > ● S3GuardRechecksNumOps (MutableQuantiles) Number of times a consistency > recheck was required while attempting to achieve consistency. > ● S3GuardStoreNthPercentileLatency (MutableQuantiles) Percentile time > spent in > operations against the consistent store, including both write operations > during file system > mutations and read operations during file system consistency checks. Repeated > for > multiple percentile values of N. This metric is an indicator of latency to > the consistent > store implementation. > ● S3GuardConsistencyStoreNumOps (MutableQuantiles) Number of operations > against the consistent store, including both write operations during file > system mutations > and read operations during file system consistency checks. > ● S3GuardConsistencyStoreFailures (MutableCounterLong) Number of failures > during operations against the consistent store implementation. > ● S3GuardConsistencyStoreTimeouts (MutableCounterLong) Number of timeouts > during operations against the consistent store implementation. > ● S3GuardInconsistencies (MutableCounterLong) C ount of times S3Guard > failed to > achieve consistency, even after exhausting all rechecks. A high count may > indicate > unexpected outofband modification of the S3 bucket contents, such as by an > external > tool that does not make corresponding updates to the consistent store. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org