{"id":462708,"date":"2025-06-10T11:13:20","date_gmt":"2025-06-10T11:13:20","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=462708"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=462708","title":{"rendered":"<span>Postgres Pro OpenTelemetry \u0441ollector<\/span>"},"content":{"rendered":"<div><!--[--><!--]--><\/div>\n<div id=\"post-content-body\">\n<div>\n<div class=\"article-formatted-body article-formatted-body article-formatted-body_version-2\">\n<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<p>Hey folks, I\u2019m Alexey. I\u2019m a big fan of observability, and in this post, I want to share something I\u2019ve been working on \u2014 the\u00a0<code>pgpro-otel-collector<\/code>.<\/p>\n<p><strong>TL;DR<\/strong>:\u00a0<code>pgpro-otel-collector<\/code>\u00a0is an OpenTelemetry collector (aka monitoring agent) tailored for gathering Postgres metrics and logs \u2014 brought to you by PostgresPro.<\/p>\n<figure class=\"full-width\"><img decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/5e7\/835\/e65\/5e7835e65a80b4772b3fb2b87c97a08b.jpg\" width=\"1625\" height=\"833\" sizes=\"auto, (max-width: 780px) 100vw, 50vw\" srcset=\"https:\/\/habrastorage.org\/r\/w780\/getpro\/habr\/upload_files\/5e7\/835\/e65\/5e7835e65a80b4772b3fb2b87c97a08b.jpg 780w,&#10;       https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/5e7\/835\/e65\/5e7835e65a80b4772b3fb2b87c97a08b.jpg 781w\" loading=\"lazy\" decode=\"async\"\/><\/figure>\n<h3>A few words about OpenTelemetry<\/h3>\n<p>It makes sense to start with OpenTelemetry, but since there&#8217;s already plenty of material out there, I won\u2019t go into detail. Just a few links for reference:<\/p>\n<ul>\n<li>\n<p><a href=\"https:\/\/opentelemetry.io\/\" rel=\"noopener noreferrer nofollow\">OpenTelemetry overview on the official website<\/a><\/p>\n<\/li>\n<li>\n<p><a href=\"https:\/\/www.oreilly.com\/library\/view\/learning-opentelemetry\/9781098147174\/\" rel=\"noopener noreferrer nofollow\">Ted Young, Austin Parker.\u00a0Learning OpenTelemetry: Setting Up and Operating a Modern Observability System<\/a><\/p>\n<\/li>\n<\/ul>\n<p>One of the key components of OpenTelemetry is the\u00a0<a href=\"https:\/\/opentelemetry.io\/docs\/collector\/\" rel=\"noopener noreferrer nofollow\">OpenTelemetry Collector<\/a>. Essentially, it&#8217;s a modular toolkit \u2014 by combining different components, you can build a monitoring agent that collects the data you need and sends it where you want. If you <a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/\" rel=\"noopener noreferrer nofollow\">look inside<\/a> this toolkit, there\u2019s a lot of useful and interesting components.<\/p>\n<p>We\u2019re primarily interested in PostgreSQL, but unfortunately, the existing <a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/blob\/main\/receiver\/postgresqlreceiver\/README.md\" rel=\"noopener noreferrer nofollow\">receiver<\/a> is mostly academic \u2014 the functionality is <a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/blob\/main\/receiver\/postgresqlreceiver\/metadata.yaml\" rel=\"noopener noreferrer nofollow\">minimal<\/a>. So, we wrote our own receiver, added it to <a href=\"https:\/\/opentelemetry.io\/docs\/collector\/custom-collector\/\" rel=\"noopener noreferrer nofollow\">builder<\/a>, and the result is\u00a0<code>pgpro-otel-collector<\/code>.<\/p>\n<h3>What can\u00a0pgpro-otel-collector\u00a0do?<\/h3>\n<ul>\n<li>\n<p>Collect Postgres metrics. This is the main purpose of the collector. The receiver is built on top of a separate internal metrics library. This makes it easier to quickly add new functionality or fix issues without bureaucracy. The receiver uses the classic model: connects to Postgres and queries system catalogs. There\u2019s <a href=\"https:\/\/postgrespro.ru\/docs\/postgrespro\/17\/monitoring-stats?lang=en\" rel=\"noopener noreferrer nofollow\">a lot of data<\/a>, and figuring out what\u2019s actually useful is not trivial.<\/p>\n<\/li>\n<li>\n<p>Collect OS-level metrics via <a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/blob\/main\/receiver\/hostmetricsreceiver\/README.md\" rel=\"noopener noreferrer nofollow\"><code>hostmetrics<\/code><\/a>. CPU, memory, disk and network usage, filesystem stats, etc. Technically optional for Postgres monitoring, but often necessary.<\/p>\n<\/li>\n<li>\n<p>Collect Postgres logs via\u00a0<a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/blob\/main\/receiver\/filelogreceiver\/README.md\" rel=\"noopener noreferrer nofollow\"><code>filelog<\/code><\/a>. Postgres supports logging in CSV and JSON formats, and the collector can read both. This integrates well with the metrics collection part.<\/p>\n<\/li>\n<li>\n<p>Internal processors\u00a0for batch processing of metrics and logs. Helps prepare and optimize data before sending to the monitoring system.<\/p>\n<\/li>\n<li>\n<p>Export to OTLP-compatible backends\u00a0via\u00a0<a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector\/blob\/main\/exporter\/otlphttpexporter\/README.md\" rel=\"noopener noreferrer nofollow\"><code>otlphttp<\/code><\/a>. So far, only Elasticsearch is supported, but other backends are planned.<\/p>\n<\/li>\n<li>\n<p><a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/tree\/main\/exporter\/prometheusexporter\" rel=\"noopener noreferrer nofollow\">Prometheus exporter<\/a>\u00a0for exposing metrics. This is the easiest way to get metrics into a widely used monitoring system.<\/p>\n<\/li>\n<\/ul>\n<h3>How to use it<\/h3>\n<p>Say you have a Postgres instance you want to monitor. You install\u00a0<code>pgpro-otel-collector<\/code>\u00a0on the same host, configure the Postgres connection, and set up where to send or expose the data. That\u2019s it. One tool handles metrics, logs, and exporting to your monitoring system. The rest is up to you \u2014 for example, building Grafana dashboards.<\/p>\n<p>The collector can gather most of the PostgreSQL statistics from standard system views: client activity, replication, background writer, checkpoints, autovacuum, WAL write\/archive, I\/O, tables, indexes, queries, etc. It also supports more specific features like <a href=\"https:\/\/postgrespro.ru\/docs\/enterprise\/17\/cfs?lang=en\" rel=\"noopener noreferrer nofollow\">CFS<\/a> and\u00a0<a href=\"https:\/\/postgrespro.ru\/docs\/enterprise\/17\/cfs?lang=en\" rel=\"noopener noreferrer nofollow\"><code>pg_wait_sampling<\/code><\/a>. The full list of metrics is available\u00a0<a href=\"https:\/\/postgrespro.com\/docs\/otelcol\/0.3\/index\" rel=\"noopener noreferrer nofollow\">here<\/a>.<\/p>\n<p>Installation and startup take about <a href=\"https:\/\/postgrespro.com\/docs\/otelcol\/0.3\/index\" rel=\"noopener noreferrer nofollow\">five commands<\/a>. The default config includes minimal general metrics. For more detailed monitoring, enable and configure the relevant modules. It&#8217;s not difficult, and the package includes extended example configs for various scenarios.<\/p>\n<p>Once it\u2019s running, metrics are available at\u00a0<code>*:8889\/metrics<\/code>\u00a0(yes, the classic Prometheus export method is enabled by default).<\/p>\n<p>How you integrate it depends on your monitoring setup. If you\u2019re using the Prometheus\/VictoriaMetrics stack, you can scrape data directly. If your stack supports OTLP, configure the collector to send metrics and logs accordingly \u2014 tools like Grafana and Kibana will work out of the box.<\/p>\n<h3>What\u2019s next<\/h3>\n<p>After the public release, the plan is to continue development:<\/p>\n<ul>\n<li>\n<p>Support for additional system views and extensions<\/p>\n<\/li>\n<li>\n<p>Integration with Shardman and BiHA<\/p>\n<\/li>\n<li>\n<p>Collection of custom query-based metrics<\/p>\n<\/li>\n<li>\n<p>A Grafana dashboard included in the package<\/p>\n<\/li>\n<li>\n<p>Various internal improvements<\/p>\n<\/li>\n<\/ul>\n<h3>Retrospective<\/h3>\n<p>I\u2019ve always had an interest in monitoring systems. Back in the 2000s, I started with The Dude on Windows, briefly tried Cacti. I skipped Nagios and Graphite. In 2010, I got into Zabbix and wrote a lot of scripts \u2014 many still live on GitHub and occasionally get new issues. I wrote <a href=\"https:\/\/github.com\/lesovsky\/zabbix-extensions\" rel=\"noopener noreferrer nofollow\">Zabbix scripts<\/a> for Postgres, and ended up working with Postgres a lot.<\/p>\n<p>In 2014, I joined DataEgret and started working with Postgres daily. Often had to troubleshoot production issues without good tools \u2014 that\u2019s how\u00a0<a href=\"https:\/\/github.com\/lesovsky\/pgcenter\" rel=\"noopener noreferrer nofollow\"><code>pgcenter<\/code><\/a>\u00a0was born. Then came Prometheus and Grafana, which I still use regularly.<\/p>\n<p>Around 2017, I started building a Postgres monitoring SaaS \u2014 not just dashboards, but more intelligent functionality like config advisors based on workload and telemetry. That became\u00a0Weaponry. I worked on it for about two years, but without sales\/marketing skills, the project didn\u2019t take off. I shut it down after investing significant time and money.<\/p>\n<p>The only thing that remained was\u00a0<a href=\"https:\/\/github.com\/lesovsky\/pgscv\" rel=\"noopener noreferrer nofollow\">pgSCV<\/a>\u00a0\u2014 a tool like a Prometheus exporter for Postgres, Pgbouncer, and Patroni metrics and logs. It worked well but was tightly coupled with Prometheus, which limited flexibility. Later, I discovered OpenTelemetry and appreciated its vendor-neutral approach \u2014 it offered more flexibility and broader applicability. After that, I had no desire to continue developing pgSCV.<\/p>\n<p>After leaving consulting, I worked in DevOps roles at a few places, and eventually joined PostgresPro.<\/p>\n<p>At the end of 2023, with silent approval from my manager, a colleague and I started developing the OpenTelemetry Collector. We began with the metrics library, then moved to the collector. A few months in, my colleague left the company, and others picked up the work. Development was sporadic and low-priority \u2014 we didn\u2019t advertise it much, and not everyone who heard about it was enthusiastic.<\/p>\n<p>There were some bureaucratic hurdles along the way \u2014 writing docs, working with the build team (thanks to Viktor for his help), holding a seminar for support staff, dealing with legal and licensing. Eventually, in late 2024, we made an internal release, and two months later \u2014 a public one.<\/p>\n<p>Now the collector is available for anyone to use. In my opinion, it turned out quite well.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<p><!----><!----><\/div>\n<p><!----><!----><br \/> \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 <a href=\"https:\/\/habr.com\/ru\/articles\/902888\/\"> https:\/\/habr.com\/ru\/articles\/902888\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<div><!--[--><!--]--><\/div>\n<div id=\"post-content-body\">\n<div>\n<div class=\"article-formatted-body article-formatted-body article-formatted-body_version-2\">\n<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<p>Hey folks, I\u2019m Alexey. I\u2019m a big fan of observability, and in this post, I want to share something I\u2019ve been working on \u2014 the\u00a0<code>pgpro-otel-collector<\/code>.<\/p>\n<p><strong>TL;DR<\/strong>:\u00a0<code>pgpro-otel-collector<\/code>\u00a0is an OpenTelemetry collector (aka monitoring agent) tailored for gathering Postgres metrics and logs \u2014 brought to you by PostgresPro.<\/p>\n<figure class=\"full-width\"><\/figure>\n<h3>A few words about OpenTelemetry<\/h3>\n<p>It makes sense to start with OpenTelemetry, but since there&#8217;s already plenty of material out there, I won\u2019t go into detail. Just a few links for reference:<\/p>\n<ul>\n<li>\n<p><a href=\"https:\/\/opentelemetry.io\/\" rel=\"noopener noreferrer nofollow\">OpenTelemetry overview on the official website<\/a><\/p>\n<\/li>\n<li>\n<p><a href=\"https:\/\/www.oreilly.com\/library\/view\/learning-opentelemetry\/9781098147174\/\" rel=\"noopener noreferrer nofollow\">Ted Young, Austin Parker.\u00a0Learning OpenTelemetry: Setting Up and Operating a Modern Observability System<\/a><\/p>\n<\/li>\n<\/ul>\n<p>One of the key components of OpenTelemetry is the\u00a0<a href=\"https:\/\/opentelemetry.io\/docs\/collector\/\" rel=\"noopener noreferrer nofollow\">OpenTelemetry Collector<\/a>. Essentially, it&#8217;s a modular toolkit \u2014 by combining different components, you can build a monitoring agent that collects the data you need and sends it where you want. If you <a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/\" rel=\"noopener noreferrer nofollow\">look inside<\/a> this toolkit, there\u2019s a lot of useful and interesting components.<\/p>\n<p>We\u2019re primarily interested in PostgreSQL, but unfortunately, the existing <a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/blob\/main\/receiver\/postgresqlreceiver\/README.md\" rel=\"noopener noreferrer nofollow\">receiver<\/a> is mostly academic \u2014 the functionality is <a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/blob\/main\/receiver\/postgresqlreceiver\/metadata.yaml\" rel=\"noopener noreferrer nofollow\">minimal<\/a>. So, we wrote our own receiver, added it to <a href=\"https:\/\/opentelemetry.io\/docs\/collector\/custom-collector\/\" rel=\"noopener noreferrer nofollow\">builder<\/a>, and the result is\u00a0<code>pgpro-otel-collector<\/code>.<\/p>\n<h3>What can\u00a0pgpro-otel-collector\u00a0do?<\/h3>\n<ul>\n<li>\n<p>Collect Postgres metrics. This is the main purpose of the collector. The receiver is built on top of a separate internal metrics library. This makes it easier to quickly add new functionality or fix issues without bureaucracy. The receiver uses the classic model: connects to Postgres and queries system catalogs. There\u2019s <a href=\"https:\/\/postgrespro.ru\/docs\/postgrespro\/17\/monitoring-stats?lang=en\" rel=\"noopener noreferrer nofollow\">a lot of data<\/a>, and figuring out what\u2019s actually useful is not trivial.<\/p>\n<\/li>\n<li>\n<p>Collect OS-level metrics via <a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/blob\/main\/receiver\/hostmetricsreceiver\/README.md\" rel=\"noopener noreferrer nofollow\"><code>hostmetrics<\/code><\/a>. CPU, memory, disk and network usage, filesystem stats, etc. Technically optional for Postgres monitoring, but often necessary.<\/p>\n<\/li>\n<li>\n<p>Collect Postgres logs via\u00a0<a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/blob\/main\/receiver\/filelogreceiver\/README.md\" rel=\"noopener noreferrer nofollow\"><code>filelog<\/code><\/a>. Postgres supports logging in CSV and JSON formats, and the collector can read both. This integrates well with the metrics collection part.<\/p>\n<\/li>\n<li>\n<p>Internal processors\u00a0for batch processing of metrics and logs. Helps prepare and optimize data before sending to the monitoring system.<\/p>\n<\/li>\n<li>\n<p>Export to OTLP-compatible backends\u00a0via\u00a0<a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector\/blob\/main\/exporter\/otlphttpexporter\/README.md\" rel=\"noopener noreferrer nofollow\"><code>otlphttp<\/code><\/a>. So far, only Elasticsearch is supported, but other backends are planned.<\/p>\n<\/li>\n<li>\n<p><a href=\"https:\/\/github.com\/open-telemetry\/opentelemetry-collector-contrib\/tree\/main\/exporter\/prometheusexporter\" rel=\"noopener noreferrer nofollow\">Prometheus exporter<\/a>\u00a0for exposing metrics. This is the easiest way to get metrics into a widely used monitoring system.<\/p>\n<\/li>\n<\/ul>\n<h3>How to use it<\/h3>\n<p>Say you have a Postgres instance you want to monitor. You install\u00a0<code>pgpro-otel-collector<\/code>\u00a0on the same host, configure the Postgres connection, and set up where to send or expose the data. That\u2019s it. One tool handles metrics, logs, and exporting to your monitoring system. The rest is up to you \u2014 for example, building Grafana dashboards.<\/p>\n<p>The collector can gather most of the PostgreSQL statistics from standard system views: client activity, replication, background writer, checkpoints, autovacuum, WAL write\/archive, I\/O, tables, indexes, queries, etc. It also supports more specific features like <a href=\"https:\/\/postgrespro.ru\/docs\/enterprise\/17\/cfs?lang=en\" rel=\"noopener noreferrer nofollow\">CFS<\/a> and\u00a0<a href=\"https:\/\/postgrespro.ru\/docs\/enterprise\/17\/cfs?lang=en\" rel=\"noopener noreferrer nofollow\"><code>pg_wait_sampling<\/code><\/a>. The full list of metrics is available\u00a0<a href=\"https:\/\/postgrespro.com\/docs\/otelcol\/0.3\/index\" rel=\"noopener noreferrer nofollow\">here<\/a>.<\/p>\n<p>Installation and startup take about <a href=\"https:\/\/postgrespro.com\/docs\/otelcol\/0.3\/index\" rel=\"noopener noreferrer nofollow\">five commands<\/a>. The default config includes minimal general metrics. For more detailed monitoring, enable and configure the relevant modules. It&#8217;s not difficult, and the package includes extended example configs for various scenarios.<\/p>\n<p>Once it\u2019s running, metrics are available at\u00a0<code>*:8889\/metrics<\/code>\u00a0(yes, the classic Prometheus export method is enabled by default).<\/p>\n<p>How you integrate it depends on your monitoring setup. If you\u2019re using the Prometheus\/VictoriaMetrics stack, you can scrape data directly. If your stack supports OTLP, configure the collector to send metrics and logs accordingly \u2014 tools like Grafana and Kibana will work out of the box.<\/p>\n<h3>What\u2019s next<\/h3>\n<p>After the public release, the plan is to continue development:<\/p>\n<ul>\n<li>\n<p>Support for additional system views and extensions<\/p>\n<\/li>\n<li>\n<p>Integration with Shardman and BiHA<\/p>\n<\/li>\n<li>\n<p>Collection of custom query-based metrics<\/p>\n<\/li>\n<li>\n<p>A Grafana dashboard included in the package<\/p>\n<\/li>\n<li>\n<p>Various internal improvements<\/p>\n<\/li>\n<\/ul>\n<h3>Retrospective<\/h3>\n<p>I\u2019ve always had an interest in monitoring systems. Back in the 2000s, I started with The Dude on Windows, briefly tried Cacti. I skipped Nagios and Graphite. In 2010, I got into Zabbix and wrote a lot of scripts \u2014 many still live on GitHub and occasionally get new issues. I wrote <a href=\"https:\/\/github.com\/lesovsky\/zabbix-extensions\" rel=\"noopener noreferrer nofollow\">Zabbix scripts<\/a> for Postgres, and ended up working with Postgres a lot.<\/p>\n<p>In 2014, I joined DataEgret and started working with Postgres daily. Often had to troubleshoot production issues without good tools \u2014 that\u2019s how\u00a0<a href=\"https:\/\/github.com\/lesovsky\/pgcenter\" rel=\"noopener noreferrer nofollow\"><code>pgcenter<\/code><\/a>\u00a0was born. Then came Prometheus and Grafana, which I still use regularly.<\/p>\n<p>Around 2017, I started building a Postgres monitoring SaaS \u2014 not just dashboards, but more intelligent functionality like config advisors based on workload and telemetry. That became\u00a0Weaponry. I worked on it for about two years, but without sales\/marketing skills, the project didn\u2019t take off. I shut it down after investing significant time and money.<\/p>\n<p>The only thing that remained was\u00a0<a href=\"https:\/\/github.com\/lesovsky\/pgscv\" rel=\"noopener noreferrer nofollow\">pgSCV<\/a>\u00a0\u2014 a tool like a Prometheus exporter for Postgres, Pgbouncer, and Patroni metrics and logs. It worked well but was tightly coupled with Prometheus, which limited flexibility. Later, I discovered OpenTelemetry and appreciated its vendor-neutral approach \u2014 it offered more flexibility and broader applicability. After that, I had no desire to continue developing pgSCV.<\/p>\n<p>After leaving consulting, I worked in DevOps roles at a few places, and eventually joined PostgresPro.<\/p>\n<p>At the end of 2023, with silent approval from my manager, a colleague and I started developing the OpenTelemetry Collector. We began with the metrics library, then moved to the collector. A few months in, my colleague left the company, and others picked up the work. Development was sporadic and low-priority \u2014 we didn\u2019t advertise it much, and not everyone who heard about it was enthusiastic.<\/p>\n<p>There were some bureaucratic hurdles along the way \u2014 writing docs, working with the build team (thanks to Viktor for his help), holding a seminar for support staff, dealing with legal and licensing. Eventually, in late 2024, we made an internal release, and two months later \u2014 a public one.<\/p>\n<p>Now the collector is available for anyone to use. In my opinion, it turned out quite well.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<p><!----><!----><\/div>\n<p><!----><!----><br \/> \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 <a href=\"https:\/\/habr.com\/ru\/articles\/902888\/\"> https:\/\/habr.com\/ru\/articles\/902888\/<\/a><br \/><\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-462708","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/462708","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=462708"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/462708\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=462708"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=462708"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=462708"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}