Member since
07-26-2019
68
Posts
30
Kudos Received
10
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
15409 | 01-22-2019 02:40 PM | |
2668 | 01-09-2019 03:10 PM | |
2217 | 08-30-2018 08:14 PM | |
1670 | 08-06-2018 07:58 PM | |
4810 | 07-16-2018 07:05 PM |
07-12-2018
04:33 PM
Were you able to resolve your issue with the MonitorActivity processor @Shantanu kumar?
... View more
06-07-2018
02:39 PM
The behavior of MonitorActivity is pretty flexible, so there are some more options. If you have it set up like this (just using GenerateFlowFile in place of QueryDatabaseTable here): then MonitorActivity will send an alert (inactive) message once GenerateFlowFile has been idle for the Threshold Duration. In this example, GenerateFlowFile is set to trigger every 60 seconds on all nodes, and MonitorActivity is set with a 20-second ThresholdDuration on the Primary Node with cluster scope. What this will generate is: 0 sec - GenerateFlowFile generates a batch of flowfiles, MonitorActivity flows the batch through to PutHDFS via SUCCESS path (on any node) 20 sec - MonitorAttribute generates inactive alert flowfile via INACTIVE path (on primary node) 60 sec - GenerateFlowFile generates a batch of flowfiles, MonitorActivity flows the batch through to PutHDFS via SUCCESS path (on any node), MonitorActivity generates ACTIVITY.RESTORED flowfile via ACTIVITY.RESTORED path (on primary node) 80 sec - MonitorAttribute generates inactive alert flowfile via INACTIVE path (on primary node) 120 sec - GenerateFlowFile generates a batch of flowfiles, MonitorActivity flows the batch through to PutHDFS via SUCCESS path (on any node), MonitorActivity generates ACTIVITY.RESTORED flowfile via ACTIVITY.RESTORED path (on primary node) etc. Is this the behavior you're looking for? If not, what is the specific desired behavior?
... View more
06-05-2018
08:30 PM
3 Kudos
OBJECTIVE: Set logging level within DLM to "DEBUG" for all components to provide more detail when troubleshooting DLM/DSS issues such as pairing problems. OVERVIEW: Using some Docker and bash sleight of hand, update the logback configuration in the DLM Docker container to direct the application to log at a more verbose DEBUG level. PREREQUISITES: Root access or sudo on the DLM host. STEPS: 1. Find the running Docker container for DLM on the host running DPS/DLM. sudo docker ps Note the docker container ID running dlm-app. 2. Get the current log configuration file from the container sudo docker exec -it <container ID> /bin/cat /usr/dlm-app/conf/logback.xml | tee logback.xml.local
3. Using vi or your favorite editor, update the logging configuration section below in the new local copy logback.xml.local, setting to "DEBUG" where desired: ...
<logger name="play" level="DEBUG" />
<logger name="application" level="DEBUG" />
<root level="DEBUG">
<appender-ref ref="ASYNCFILE" />
<appender-ref ref="ASYNCSTDOUT" />
</root>
... 4. Deploy the new configuration to the Docker container sudo docker exec -i <container ID> cp /usr/dlm-app/conf/logback.xml /usr/dlm-app/conf/logback.xml.bak
sudo docker exec -i <container ID> tee /usr/dlm-app/conf/logback.xml < logback.xml.local
5. Restart the Docker container sudo docker restart <container ID>
6. View the log output sudo docker exec -it <container ID> /bin/tailf /usr/dlm-app/logs/application.log
or sudo docker logs <container ID>
To restore the previous level of logging, replace /usr/dlm-app/logs/application.log with the backup made in step 4 (/usr/dlm-app/conf/logback.xml.bak).
... View more
Labels:
06-02-2018
12:38 AM
It looks like the Threshold Duration is set to 1 minute in the configuration pictured. In that case, the processor started at 10:00 would trigger an inactivity message if the upstream processor had not generated a flowfile for the past 60 seconds. All flowfiles passed to the MonitorActivity processor will also be passed through to the Success relationship when the processor starts. If instead the desired action is to send a dummy flowfile only if there has been no activity on the QueryDatabaseTable processor for one hour, scheduling both to run at 9:00 with a 60 minute threshold on the MonitorActivity should work.
... View more
06-01-2018
01:13 PM
Can you share the configuration of your MonitorActivity processor?
... View more
06-01-2018
01:10 PM
Glad it worked! If this answer helps, please mark it as an accepted answer, too!
... View more
05-31-2018
09:38 PM
Is it possible that something in your original redirection to the file was removing a character or two? As pasted into your original question, it's invalid JSON, which would also give you an error (since jq would be trying to parse a non-parseable string). Just to be thorough, could you attach the original file?
... View more
05-31-2018
09:36 PM
Is it possible that something in your original redirection to the file is removing a character or two? As pasted into your original question, it's invalid JSON, which would also give you an error (since jq would be trying to parse a non-parseable string).
... View more
05-31-2018
09:27 PM
by-duration is specified relative to the current time, but --to-datetime is in UTC unless otherwise specified. Since you are on BST (British Summer Time), you'd need to use UTC+1, specifying "--to-datetime 2018-05-31T14:00:00.000+01" to get the same result - assuming I have my ISO standards right...
... View more
05-31-2018
09:09 PM
jq '.items[].Clusters.health_report."Host/host_status/UNHEALTHY"' should work. The key name Host/host_status/UNHEALTHY should be quoted to escape the forward slashes in the name.
... View more