Github user nickwallen commented on a diff in the pull request:

    https://github.com/apache/incubator-metron/pull/395#discussion_r93316759
  
    --- Diff: metron-analytics/metron-profiler-client/README.md ---
    @@ -86,4 +71,73 @@ Returns: The profile measurements.
     [12078.0, 8921.0, 12131.0]
     ```
     
    -The client API call above has retrieved the past hour of the 'test' 
profile for the entity '192.168.138.158'.
    \ No newline at end of file
    +The client API call above has retrieved the past hour of the 'test' 
profile for the entity '192.168.138.158'.
    +
    +### Configuration
    +
    +By default, the Profiler creates Profiles with a period duration of 15 
minutes. This means that data is accumulated, summarized and flushed every 15 
minutes. The Client API must also have knowledge of this duration to correctly 
retrieve the profile data. If the client API is expecting 15 minute periods, it 
will not be able to read data generated by a Profiler that has been configured 
with a 1 hour period.
    +
    +The period duration can be configured in the Profiler by altering the 
Profiler topology's static properties file 
(`$METRON/config/profiler.properties`). The Stellar Client API can be 
configured by setting the following properties in Metron's global configuration.
    +
    +| Key                                   | Description                      
                                                                                
                  | Required | Default  |
    +| ------------------------------------- | -------- | -------- | -------- |
    +| profiler.client.period.duration       | The duration of each profile 
period.  This value should be defined along with 
`profiler.client.period.duration.units`.  | Optional | 15       |
    +| profiler.client.period.duration.units | The units used to specify the 
profile period duration.  This value should be defined along with 
`profiler.client.period.duration`. | Optional | MINUTES  |
    +| profiler.client.hbase.table           | The name of the HBase table used 
to store profile data. | Optional | profiler |
    +| profiler.client.hbase.column.family         | The name of the HBase 
column family used to store profile data. | Optional | P |
    +| profiler.client.salt.divisor          | The salt divisor used to store 
profile data. | Optional | 1000     |
    +| hbase.provider.impl                   | The name of the 
HBaseTableProvider implementation class. | Optional |          |
    +
    +### Functions
    +
    +#### `PROFILE_GET`
    +
    +Retrieves a series of values from a stored profile.
    +
    +Arguments
    + * profile - The name of the profile.
    + * entity - The name of the entity.
    + * durationAgo - How long ago should values be retrieved from?
    + * units - The units of 'durationAgo'.
    + * groups - Optional - The groups used to sort the profile.
    +
    +Returns
    + * The profile measurements.
    +
    +Examples
    +
    +Retrieve the last 30 minutes of measurements for profile 'profile1' and 
entity '10.0.0.1'.
    +```
    +PROFILE_GET('profile1', '10.0.0.1', 30, 'MINUTES')
    +```
    +
    +Retrieve the last 30 minutes of measurements for profile 'profile1' and 
entity '10.0.0.1' in the group named 'mondays'.
    +```
    +PROFILE_GET('profile1', '10.0.0.1', 30, 'MINUTES', 'mondays')
    +```
    +
    +#### `PROFILE_GET_FROM`
    +
    +Retrieves a series of values from a stored profile.
    +
    +Arguments
    + * profile - The name of the profile.
    + * entity - The name of the entity.
    + * lookBack - How long to look back in milliseconds
    + * offset - Optional - When to start the look back from in epoch 
milliseconds. Defaults to current time.
    + * groups - Optional - The groups used to sort the profile.
    --- End diff --
    
    For the sake of simplicity and the fact that we already have `PROFILE_GET` 
that effectively assumes `NOW()`, I simply made the `offset` a required 
argument.
    
    I find using a map to fake named parameters not that intuitive.  I'm fine 
with doing it where we have no better alternative today, but if we can, I'd 
prefer to avoid.  
    
    If we want named arguments, which I think would be **very** useful, then we 
should add them to the language.
    



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to