[FLINK-5796] [docs] Fix broken links

This closes apache#3308.

docs/dev/batch/index.md

@@ -2135,7 +2135,7 @@ Passing Parameters to Functions
 
 Parameters can be passed to functions using either the constructor or the `withParameters(Configuration)` method. The parameters are serialized as part of the function object and shipped to all parallel task instances.
 
-Check also the [best practices guide on how to pass command line arguments to functions]({{ site.baseurl }}/monitoring/best_practices.html#parsing-command-line-arguments-and-passing-them-around-in-your-flink-application).
+Check also the [best practices guide on how to pass command line arguments to functions]({{ site.baseurl }}/dev/best_practices.html#parsing-command-line-arguments-and-passing-them-around-in-your-flink-application).
 
 #### Via Constructor
 

docs/dev/datastream_api.md

@@ -1595,7 +1595,7 @@ for an explanation of most parameters. These parameters pertain specifically to
 
 ### Fault Tolerance
 
-[State & Checkpointing]({{ site.baseurl }}/dev/state#enabling-checkpointing) describes how to enable and configure Flink's checkpointing mechanism. 
+[State & Checkpointing]({{ site.baseurl }}/dev/stream/checkpointing) describes how to enable and configure Flink's checkpointing mechanism.
 
 ### Controlling Latency
 

docs/internals/stream_checkpointing.md

@@ -103,7 +103,7 @@ the barrier *n* from the other inputs as well. Otherwise, it would have mixed re
 
 When operators contain any form of *state*, this state must be part of the snapshots as well. Operator state comes in different forms:
 
- - *User-defined state*: This is state that is created and modified directly by the transformation functions (like `map()` or `filter()`). User-defined state can either be a simple variable in the function's java object, or the associated key/value state of a function (see [State in Streaming Applications]({{ site.baseurl }}/dev/state.html) for details).
+ - *User-defined state*: This is state that is created and modified directly by the transformation functions (like `map()` or `filter()`). User-defined state can either be a simple variable in the function's java object, or the associated key/value state of a function (see [State in Streaming Applications]({{ site.baseurl }}/dev/stream/state.html) for details).
  - *System state*: This state refers to data buffers that are part of the operator's computation. A typical example for this state are the *window buffers*, inside which the system collects (and aggregates) records for windows until the window is evaluated and evicted.
 
 Operators snapshot their state at the point in time when they received all snapshot barriers from their input streams, before emitting the barriers to their output streams. At that point, all updates to the state from records before the barriers will have been made, and no updates that depend on records from after the barriers have been applied. Because the state of a snapshot may be potentially large, it is stored in a configurable *state backend*. By default, this is the JobManager's memory, but for serious setups, a distributed reliable storage should be configured (such as HDFS). After the state has been stored, the operator acknowledges the checkpoint, emits the snapshot barrier into the output streams, and proceeds.
@@ -142,7 +142,7 @@ It is possible to let an operator continue processing while it stores its state
 
 After receiving the checkpoint barriers on its inputs, the operator starts the asynchronous snapshot copying of its state. It immediately emits the barrier to its outputs and continues with the regular stream processing. Once the background copy process has completed, it acknowledges the checkpoint to the checkpoint coordinator (the JobManager). The checkpoint is now only complete after all sinks received the barriers and all stateful operators acknowledged their completed backup (which may be later than the barriers reaching the sinks).
 
-See [State Backends]({{ site.baseurl }}/internals/state_backends.html) for details on the state snapshots.
+See [State Backends]({{ site.baseurl }}/ops/state_backends.html) for details on the state snapshots.
 
 
 ## Recovery

docs/ops/state_backends.md

@@ -28,7 +28,7 @@ Programs written in the [Data Stream API]({{ site.baseurl }}/dev/datastream_api.
 - Transformation functions may use the key/value state interface to store values
 - Transformation functions may implement the `Checkpointed` interface to make their local variables fault tolerant
 
-See also [Working with State]({{ site.baseurl }}/dev/state.html) in the streaming API guide.
+See also [Working with State]({{ site.baseurl }}/dev/stream/state.html) in the streaming API guide.
 
 When checkpointing is activated, such state is persisted upon checkpoints to guard against data loss and recover consistently.
 How the state is represented internally, and how and where it is persisted upon checkpoints depends on the

docs/redirects/best_practices.md

@@ -1,7 +1,7 @@
 ---
 title: "Best Practices"
 layout: redirect
-redirect: /monitoring/best_practices.html
+redirect: /dev/best_practices.html
 permalink: /apis/best_practices.html
 ---
 <!--

docs/redirects/fault_tolerance.md

@@ -1,7 +1,7 @@
 ---
 title: "Fault Tolerance"
 layout: redirect
-redirect: /dev/state.html
+redirect: /dev/stream/state.html
 permalink: /apis/streaming/fault_tolerance.html
 ---
 <!--