Repairs several broken links in the docs

sections/production/measurememory.basque.md

@@ -10,15 +10,15 @@ Mundu perfektu batean, web garatzaile batek ez luke memoria ihesei aurre egin be
 
 ### Beste blogari batzuek diotena
 
-[Dyntrace](http://apmblog.dynatrace.com/) bloga:
+[Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/) bloga:
 
 > ... ”Dagoeneko badakigun bezala, Node.jsen V8k jatorrizko kodean konpilatzen du JavaScript. Sortzen diren jatorrizko datu egiturek ez dute zerikusi handirik jatorrizko irudikapenarekin, eta V8k kudeatzen ditu soilik. Horrek esan nahi du ezin dugula memoria aktiboki esleitu edo banatu JavaScripten. V8k zabor bilketa izeneko mekanismo ezaguna erabiltzen du arazo horri aurre egiteko".
 
 [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load) bloga:
 
 > ... ... "Adibide honek ageriko emaitzak lortzen baditu ere, prozesua beti berdina da: sortu pila zabortegiak denbora pixka bat eta memoria asko esleituta. Konparatu zabortegi batzuk zer hazten ari den jakiteko"
 
-[Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load) bloga:
+[Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/) bloga:
 
 > ... “hutsegitea, Node.js 1,5 GB memoria inguru erabiltzen saiatuko da, eta hori mugatu egin behar da memoria gutxiago duten sistemetan exekutatzen denean. Hori da espero den jokabidea, zabor bilketa oso operazio garestia baita. Horren irtenbidea izan zen Node.js prozesuari beste parametro bat gehitzea: nodo –max_old_space_size = 400 server.js –production . "
 

sections/production/measurememory.brazilian-portuguese.md

@@ -10,15 +10,15 @@ Em um mundo perfeito, um desenvolvedor Web não deve lidar com vazamentos de mem
 
 ### O que Outros Blogueiros Dizem
 
-* Do blog [Dyntrace](http://apmblog.dynatrace.com/):
+* Do blog [Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/):
 > ... ”Como já aprendemos, no Node.js o JavaScript é compilado para código nativo pelo V8. As estruturas de dados nativas resultantes não têm muito a ver com a representação original e são gerenciadas exclusivamente pelo V8. Isso significa que não podemos alocar ou desalocar ativamente a memória em JavaScript. O V8 usa um mecanismo bem conhecido chamado coleta de lixo para resolver esse problema.”
 
 * Do blog [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
 > ... “Embora este exemplo leve a resultados óbvios, o processo é sempre o mesmo:
 Crie dumps de heap com algum tempo e uma boa quantidade de alocação de memória entre
 Compare alguns dumps para descobrir o que está crescendo”
 
-* Do blog [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
+* Do blog [Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/):
 > ... “falha, o Node.js tentará usar cerca de 1,5 GB de memória, que deve ser limitado quando executado em sistemas com menos memória. Esse é o comportamento esperado, pois a coleta de lixo é uma operação muito cara.
 A solução para isso foi adicionar um parâmetro extra ao processo Node.js:
 node –max_old_space_size=400 server.js –production ”

sections/production/measurememory.chinese.md

@@ -11,13 +11,13 @@
 
 ### 其他博客说了什么
 
-* 摘自博客 [Dyntrace](http://apmblog.dynatrace.com/):
+* 摘自博客 [Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/):
 > ... ”正如我们所了解到的，在Node.js 中，JavaScript被V8编译为机器码。由此产生的机器码数据结构与原始表达没有多大关系，只能由V8管理. 这意味着我们不能主动分配或释放JavaScript中的内存. V8 使用了一个众所周知的垃圾收集机制来解决这个问题.”
 
 * 摘自博客 [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
 > ... “虽然这个例子导致了明显的结果，但这个过程总是一样的：用一些时间和相当数量的内存分配创建heap dumps，比较dumps，以找出正在增长的内存泄露。”
 
-* 摘自博客 [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
+* 摘自博客 [Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/):
 > ... “故障, 在内存较少的系统上运行时必须限制内存，Node.js会尝试使用大约1.5GB的内存。这是预期的行为，垃圾收集是一个代价很高的操作。
 解决方案是为Node.js进程添加一个额外的参数:
 node –max_old_space_size=400 server.js –production ”

sections/production/measurememory.french.md

@@ -10,15 +10,15 @@ Dans un monde parfait, un développeur web ne devrait pas s'occuper des fuites d
 
 ### Ce que disent les autres blogueurs
 
-* Extrait du blog de [Dyntrace](http://apmblog.dynatrace.com/) :
+* Extrait du blog de [Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/) :
 > ... « Comme nous l'avons déjà appris, dans Node.js, JavaScript est compilé en code natif par V8. Les structures de données natives résultantes n'ont pas grand-chose à voir avec leur représentation d'origine et sont uniquement gérées par V8. Cela signifie que nous ne pouvons pas allouer ou désallouer activement de la mémoire en JavaScript. V8 utilise un mécanisme bien connu appelé le [ramasse-miettes](https://fr.wikipedia.org/wiki/Ramasse-miettes_(informatique)) (NdT *garbage collection*) pour résoudre ce problème. »
 
 * Extrait du blog de [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load) :
 > ... « Bien que cet exemple mène à des résultats évidents, le processus est toujours le même :
 Créez des copies de mémoires sur une certaine période avec une bonne quantité d'allocation de mémoire entre les deux
 Comparez ces copies pour découvrir ce qui augmente »
 
-* Extrait du blog de [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load) :
+* Extrait du blog de [Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/) :
 > ... « Par défaut, Node.js essaiera d'utiliser environ 1,5GB de mémoire, ce qui doit être plafonné lors de l'exécution sur des systèmes avec moins de mémoire. C'est le comportement attendu car la récupération de place est une opération très coûteuse.
 La solution pour cela a été d'ajouter un paramètre supplémentaire au processus de Node.js :
 node –max_old_space_size=400 server.js –production »

sections/production/measurememory.japanese.md

@@ -10,15 +10,15 @@
 
 ### 他のブロガーが言っていること
 
-* ブログ [Dyntrace](http://apmblog.dynatrace.com/) より:
+* ブログ [Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/) より:
 > ... ”すでに学習したように、Node.js JavaScript は V8 でネイティブコードにコンパイルされています。結果として得られるネイティブなデータ構造は、元の表現とはあまり関係がなく、もっぱら V8 によって管理されています。つまり、JavaScript では能動的にメモリを割り当てたり、解放したりすることができません。V8 はこの問題に対処するために、ガベージコレクションと呼ばれるよく知られたメカニズムを使用しています。”
 
 * ブログ [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load) より:
 > ... “この例では明らかな結果が得られますが、プロセスは常に同じです。:
 ある程度の時間をかけてヒープダンプを作成し、その間にかなりの量のメモリ割り当てを行います。
 いくつかのダンプを比較して、何が成長しているかを確認します。”
 
-* ブログ [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load) より:
+* ブログ [Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/) より:
 > ... “デフォルトでは、Node.js は約1.5 GB のメモリを使用しようとしますが、メモリの少ないシステムで実行する場合は上限を設定する必要があります。ガベージコレクションは非常にコストのかかる操作なので、これは予想される動作です。
 これを解決するには、Node.js のプロセスに余分なパラメータを追加する必要がありました。:
 node –max_old_space_size=400 server.js –production ”

sections/production/measurememory.korean.md

@@ -10,15 +10,15 @@ In a perfect world, a web developer shouldn’t deal with memory leaks. In reali
 
 ### What Other Bloggers Say
 
-* From the blog [Dyntrace](http://apmblog.dynatrace.com/):
+* From the blog [Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/):
 > ... ”As we already learned, in Node.js JavaScript is compiled to native code by V8. The resulting native data structures don’t have much to do with their original representation and are solely managed by V8. This means that we cannot actively allocate or deallocate memory in JavaScript. V8 uses a well-known mechanism called garbage collection to address this problem.”
 
 * From the blog [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
 > ... “Although this example leads to obvious results the process is always the same:
 Create heap dumps with some time and a fair amount of memory allocation in between
 Compare a few dumps to find out what’s growing”
 
-* From the blog [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
+* From the blog [Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/):
 > ... “fault, Node.js will try to use about 1.5GBs of memory, which has to be capped when running on systems with less memory. This is the expected behavior as garbage collection is a very costly operation.
 The solution for it was adding an extra parameter to the Node.js process:
 node –max_old_space_size=400 server.js –production ”

sections/production/measurememory.md

@@ -10,15 +10,15 @@ In a perfect world, a web developer shouldn’t deal with memory leaks. In reali
 
 ### What Other Bloggers Say
 
-* From the blog [Dyntrace](http://apmblog.dynatrace.com/):
+* From the blog [Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/):
 > ... ”As we already learned, in Node.js JavaScript is compiled to native code by V8. The resulting native data structures don’t have much to do with their original representation and are solely managed by V8. This means that we cannot actively allocate or deallocate memory in JavaScript. V8 uses a well-known mechanism called garbage collection to address this problem.”
 
 * From the blog [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
 > ... “Although this example leads to obvious results the process is always the same:
 Create heap dumps with some time and a fair amount of memory allocation in between
 Compare a few dumps to find out what’s growing”
 
-* From the blog [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
+* From the blog [Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/):
 > ... “fault, Node.js will try to use about 1.5GBs of memory, which has to be capped when running on systems with less memory. This is the expected behavior as garbage collection is a very costly operation.
 The solution for it was adding an extra parameter to the Node.js process:
 node –max_old_space_size=400 server.js –production ”

sections/production/measurememory.polish.md

@@ -10,15 +10,15 @@ W idealnym świecie programista nie powinien zajmować się wyciekami pamięci.
 
 ### Co mówią inni blogerzy
 
-* Z bloga [Dyntrace](http://apmblog.dynatrace.com/):
+* Z bloga [Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/):
 > ... ”As we already learned, in Node.js JavaScript is compiled to native code by V8. The resulting native data structures don’t have much to do with their original representation and are solely managed by V8. This means that we cannot actively allocate or deallocate memory in JavaScript. V8 uses a well-known mechanism called garbage collection to address this problem.”
 
 * Z bloga [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
 > ... “Although this example leads to obvious results the process is always the same:
 Create heap dumps with some time and a fair amount of memory allocation in between
 Compare a few dumps to find out what’s growing”
 
-* Z bloga [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
+* Z bloga [Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/):
 > ... “fault, Node.js will try to use about 1.5GBs of memory, which has to be capped when running on systems with less memory. This is the expected behavior as garbage collection is a very costly operation.
 The solution for it was adding an extra parameter to the Node.js process:
 node –max_old_space_size=400 server.js –production ”

sections/production/measurememory.russian.md

@@ -10,15 +10,15 @@
 
 ### Что говорят другие блоггеры
 
-* Из блога [Dyntrace](http://apmblog.dynatrace.com/):
+* Из блога [Dyntrace](https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/):
 > ... "Как мы уже узнали, в Node.js JavaScript компилируется в нативный код V8. Получающиеся в результате собственные структуры данных не имеют большого отношения к их исходному представлению и управляются исключительно V8. Это означает, что мы не можем активно выделять или освобождать память в JavaScript. V8 использует хорошо известный механизм сбора мусора для решения этой проблемы".
 
 * Из блога [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
 > ... "Хотя этот пример приводит к очевидным результатам, процесс всегда один и тот же:
 Создайте дампы кучи с некоторым временем и достаточным количеством памяти, выделяемой между ними
 Сравните несколько свалок, чтобы узнать, что растет"
 
-* Из блога [Dyntrace](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
+* Из блога [Rising Stack](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/):
 > ... "ошибка, Node.js попытается использовать около 1,5ГБ памяти, которая должна быть ограничена при работе в системах с меньшим объемом памяти. Это ожидаемое поведение, поскольку сборка мусора является очень дорогостоящей операцией.
 Решением для этого было добавление дополнительного параметра в процесс Node.js:
 node –max_old_space_size=400 server.js –production"

sections/production/monitoring.basque.md

@@ -30,7 +30,7 @@ Funtzio aurreratuak lortu nahi badituzu, konfigurazio luzea egin beharko duzu ed
 
 ### Beste blogari batzuek diotena
 
-[Rising Stack](http://mubaloo.com/best-practices-deploying-node-js-applications/) bloga :
+[Rising Stack](https://blog.risingstack.com/node-js-performance-monitoring-with-prometheus/) bloga :
 
 > …Zure zerbitzu guztietako seinale horiek ikustea gomendatzen dizugu.
 > Errorea: erroreek erabiltzaileei aurre egiten dietelako eta zure bezeroei berehala eragiten dietelako

sections/production/monitoring.brazilian-portuguese.md

@@ -30,7 +30,7 @@ Atingir os recursos avançados exige uma configuração demorada ou a compra de
 
 ### O que Outros Blogueiros Dizem
 
-Do blog [Rising Stack](http://mubaloo.com/best-practices-deploying-node-js-applications/):
+Do blog [Rising Stack](https://blog.risingstack.com/node-js-performance-monitoring-with-prometheus/):
 
 > …Recomendamos que você observe esses sinais para todos os seus serviços:
 > Taxa de erros: porque os erros são enfrentados pelo usuário e afetam imediatamente seus clientes.

sections/production/monitoring.chinese.md

@@ -30,7 +30,7 @@
 
 <br/><br/>
 ### 其他博主说了什么
-  摘自博客 [Rising Stack](http://mubaloo.com/best-practices-deploying-node-js-applications/):
+  摘自博客 [Rising Stack](https://blog.risingstack.com/node-js-performance-monitoring-with-prometheus/):
 
 > ...我们建议您为所有服务监听这些信号：
 > 错误率：因为错误是用户面对的，并立即会影响您的客户。

sections/production/monitoring.french.md

@@ -30,7 +30,7 @@ La réalisation des fonctionnalités avancées nécessite une configuration long
 
 ### Ce que disent les autres blogueurs
 
-Extrait du blog de [Rising Stack](http://mubaloo.com/best-practices-deploying-node-js-applications/) :
+Extrait du blog de [Rising Stack](https://blog.risingstack.com/node-js-performance-monitoring-with-prometheus/) :
 
 > …Nous vous recommandons de surveiller ces signaux pour tous vos services :
 > Taux d'erreur : parce que les erreurs sont confrontées à l'utilisateur et affectent immédiatement vos clients.

sections/production/monitoring.japanese.md

@@ -29,7 +29,7 @@
 
 ### 他のブロガーが言っていること
 
-[Rising Stack](http://mubaloo.com/best-practices-deploying-node-js-applications/) のブログより:
+[Rising Stack](https://blog.risingstack.com/node-js-performance-monitoring-with-prometheus/) のブログより:
 
 > ...すべてのサービスのために、これらの信号を見ることをお勧めします:
 > エラー率: なぜなら、エラーはユーザーが直面するものであり、すぐに顧客に影響を与えるからです。

sections/production/monitoring.korean.md

@@ -30,7 +30,7 @@ Achieving the advanced features demands lengthy setup or buying a commercial pro
 
 ### What Other Bloggers Say
 
-From the blog [Rising Stack](http://mubaloo.com/best-practices-deploying-node-js-applications/):
+From the blog [Rising Stack](https://blog.risingstack.com/node-js-performance-monitoring-with-prometheus/):
 
 > …We recommend you to watch these signals for all of your services:
 > Error Rate: Because errors are user facing and immediately affect your customers.

sections/production/monitoring.md

@@ -30,7 +30,7 @@ Achieving the advanced features demands lengthy setup or buying a commercial pro
 
 ### What Other Bloggers Say
 
-From the blog [Rising Stack](http://mubaloo.com/best-practices-deploying-node-js-applications/):
+From the blog [Rising Stack](https://blog.risingstack.com/node-js-performance-monitoring-with-prometheus/):
 
 > …We recommend you to watch these signals for all of your services:
 > Error Rate: Because errors are user facing and immediately affect your customers.

sections/production/monitoring.polish.md

@@ -30,7 +30,7 @@ Osiągnięcie zaawansowanych funkcji wymaga długiej konfiguracji lub zakupu kom
 
 ### Co mówią inni blogerzy
 
-Z bloga [Rising Stack](http://mubaloo.com/best-practices-deploying-node-js-applications/):
+Z bloga [Rising Stack](https://blog.risingstack.com/node-js-performance-monitoring-with-prometheus/):
 
 > …We recommend you to watch these signals for all of your services:
 > Error Rate: Because errors are user facing and immediately affect your customers.