Member since
10-29-2015
125
Posts
31
Kudos Received
4
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1030 | 06-27-2024 02:42 AM | |
2487 | 06-24-2022 09:06 AM | |
3904 | 01-19-2021 06:56 AM | |
56436 | 01-18-2016 06:59 PM |
06-26-2024
04:06 AM
Hello, We are on CDP PB 7.1.9 and goal is to monitor YARN applications and performance along with few HDFS metrics on Grafana via dashboards and ultimately trigger alerts. Metrics has to be collected via Prometheus agent and shared with Grafana. At this point, I have downloaded a Prometheus agent and created a below yml configuration. I understand this will collect all the metrics, which is intentional to start with. lowercaseOutputName: true
rules:
# All Gauge type Hadoop Metrics
- pattern: 'hadoop<name=.*><>(Count|Value)'
name: hadoop_${1}_gauge
type: GAUGE
# All Counter type Hadoop Metrics
- pattern: 'hadoop<name=.*><>(Count|Value)'
name: hadoop_${1}_counter
type: COUNTER Prometheus agent jar and this config file is stored at /var/lib/prometheus_jmx_config/. For now testing this only on resource manager instances to verify if metrics are getting collected. Following few articles and Grafana documentation, I understood that I will need to run Prometheus as a Java agent (our case) or a stand alone HTTP server. To achieve this, we need to expose / enable JMX for the components we need to monitor (Resource Manager in this case) which has to be done by adding java agent command in hadoop-env.sh. Referring to the documentation, below is the command I think should work: YARN_RESOURCEMANAGER_OPTS="-javaagent:/var/lib/prometheus_jmx_config/jmx_prometheus_javaagent-0.20.0.jar=9091:/var/lib/prometheus_jmx_config/hadoop_jmx_exporter.yml" I tried adding this command in Gateway Client Environment Advanced Configuration Snippet (Safety Valve) for hadoop-env.sh of YARN configuration and it prompted to restart impacted services as this would change yarn-conf for multiple services. However, YARN service (RM to be specific) was never restarted. So I restarted it thinking it will execute prometheus agent as Java process and ultimately enable JMX on port 9091. However, the agent never started so JMX did not got enabled. We also have few Java related properties specific to components like below: Java Configuration Options for NodeManager Java Configuration Options for ResourceManager However, as I am not confident if those are correct, would be great if someone could advise on the same or if any configuration that I have missed. Thanks Snm1523
... View more
Labels:
06-21-2024
07:27 AM
1 Kudo
Hello @wbekker, Which one and how did you turned it off? Thanks snm1523
... View more
06-07-2024
01:19 AM
1 Kudo
UPDATE: There were configs done incorrectly in topology files due to which I was unable to access Service UIs. Fixing the topology config file helped.
... View more
06-05-2024
02:30 AM
1 Kudo
Thank you for the detailed explanation, @ShankerSharma. However, we ultimately had the engineering team along with developers who did this job. But I will keep this in my notes for reference.
... View more
06-05-2024
02:26 AM
1 Kudo
Hello @Dennisleonn, Thank you for the detailed explanation and response. Certainly helped to understand the way Knox and Ranger work together. With respect to the issue Knox being not able to write the audit logs, I was able to get it through by changing the authorization type to "XASecurePDPKnox", which pushed Knox to use Ranger for authorizations and ultimately started writing audits to HDFS. However, I am now stuck on next issue where, I am unable to access the service URLs from Knox as regardless of the permissions in ranger policies for respective service, access is denied. Same is seen on Ranger Admin UI as well, which confirms ranger is denying access to service UIs via custom topology. All works okay with default (cdp-proxy) topology. I am pretty sure something basic is missed. But unable to get hold of it. Any clue on this? Thanks snm1523
... View more
05-23-2024
04:09 AM
Hello, Has anyone encountered an issue were Knox is not writing audit logs of specific topology. We have below topologies created including few of them migrated from HDP, however, necessary modifications were done and are listed in Knox UI. cdp-proxy cdp-proxy-api cdp-proxy-token health tokenexchange user1 - created for user group topo1 - created for user group and migrated from HDP topo2 - created for user group and migrated from HDP app - Used by app accounts Knox is successfully writing Ranger audit logs in HDFS for only cdp* topologies which were created by Cloudera during setup of Knox service and not for other. Written logs are visible in access tab of Audit section in Ranger Admin UI. We have total of 3 clusters and this is the case 2 clusters, for 1 cluster everything works fine. I have compared the configuration and also topology xmls and all seems correct (except for instance details which is obvious). Would it be anything related to Ranger or Solr configuration for Knox? However, if that is case it should be applicable to all topologies of Knox, why only non-default ones? Please help with suggestions / things to check / troubleshoot. Thanks snm1523
... View more
Labels:
05-20-2024
03:53 AM
1 Kudo
Hello @Scharan, I did found this sometimes back. 🙂 However, thank you for reconfirming my understanding. Thanks snm1523
... View more
05-20-2024
01:34 AM
1 Kudo
Hello, We have recently migrated from HDP to CDP 7.1.9 and new Knox topologies created as per Cloudera recommendations (cdp-proxy, cdp-proxy-api and cdp-proxy-token) are in place and configured. However, for some reason the topologies from HDP environment are also inherited and are visible on Knox UI, though are not active / used. Kindly advise on below points: 1. Is this a normal behaviour that Knox topologies get inherited OR we missed something? 2. How do we delete these unwanted topologies so they don't appear in Knox UI. 3. There are some topologies that we would still need, however, few services like Ambari and Zeppelin are not needed. How do I remove these from an existing topology? Thanks snm1523
... View more
Labels:
05-16-2024
02:35 AM
1 Kudo
Thank you for the explanation @Rajat_710. This helps. So once the logs from spool are processed they are moved to archive and hence, safe to be deleted, correct? Secondly, for SMM, logs are not going to HDFS at all. Is there a way to configure audit logs of SMM to go to HDFS like we are sending for other services? I did not see the configuration anywhere in SMM to enable this. Thanks snm1523
... View more
05-15-2024
01:12 AM
1 Kudo
Hello, Any clue on how we configure Streams Messaging Manager server to send audit logs to HDFS and / or Solr (just like other services) and then they would get archived to /archive directory from where we can manually delete them? I am referring to logs that get stored under below location locally (not HDFS) /var/log/streams-messaging-manager/audit/<hdfs or solr>/spool Thanks snm1523
... View more